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Executive  Summary 


This  report  assesses  the  test  adequacy,  operational  effectiveness,  operational  suitability, 
and  survivability  of  the  Joint  Battle  Command-Platform  (JBC-P).  The  Multi-Service  Operational 
Test  and  Evaluation  (MOT&E)  results  are  intended  to  provide  input  to  an  Army  materiel  release 
decision  and  a  Marine  Corps  fielding  decision  for  JBC-P  Software  Build  6.0.  During  the  test, 
DOT&E  assessed  new  capabilities  and  verification  of  correction  of  deficiencies  from  the  JBC-P 
Software  Build  5.0  Initial  Operational  Test  and  Evaluation,  which  was  conducted  during  the 
Army’s  Network  Integration  Evaluation  (NIE)  13.2  in  May  2013. 

The  Army  Test  and  Evaluation  Command  conducted  the  JBC-P  MOT&E,  from  April  23 
through  May  17,  2014,  at  Fort  Bliss,  Texas,  and  White  Sands  Missile  Range  (WSMR),  New 
Mexico.  The  JBC-P  MOT&E  was  conducted  as  part  of  the  Army’s  NIE  14.2,  and  included  a 
Pilot  Test  (April  28  through  May  2)  and  a  Record  Test  (May  6  -17).  The  test  location  was  a 
dispersed  desert  environment  with  limited  urban  terrain.  The  Army  and  Marine  Corps’  testing  of 
JBC-P  was  adequate  and  was  conducted  in  accordance  with  a  DOT&E-approved  test  plan.  The 
Army  also  included  JBC-P  Software  Build  6.0,  modified  with  fixes,  as  a  baseline  system  in  NIE 
15.1,  October  15  to  November  2,  2014,  and  collected  Soldier  surveys  and  observations  on  the 
system’s  performance. 

The  JBC-P  MOT&E  test  units  consisted  of  the  Army’s  2nd  Brigade,  1st  Armored  Division 
(2/1  AD),  configured  as  a  heavy  brigade  combat  team  with  brigade  headquarters  and  six 
battalions,  and  the  Marine  Corps’  2-8th  Infantry  Battalion  (under  operational  control  of  the  2/1 
AD).  The  brigade  was  equipped  with  JBC-P  and  predecessor  systems  including  Force  XXI 
Battle  Command,  Brigade  and  Below  Joint  Capabilities  Release  (FBCB2  JCR),  and  FBCB2 
Version  6.5.  The  units  conducted  operationally  realistic  scenarios  to  include  offensive, 
defensive,  and  stability  missions  with  JBC-P  employed  at-the-halt  and  on-the-move. 

Operational  Effectiveness 

The  Joint  Battle  Command  -  Platform  (JBC-P)  Software  Build  6.0  is  not  operationally 
effective.  It  did  not  demonstrate  the  ability  to  support  Army  and  Marine  Corps  leaders,  Soldiers, 
and  Marines  with  the  critical  capabilities  of  Command  and  Control  (C2)  messages,  and 
Survivability/Entity  Data  messages  when  operating  from  Tactical  Operational  Centers  (TOCs) 
and  on-the-move  in  tactical  vehicles.  Several  JBC-P  software  deficiencies  reduced  the  units’ 
ability  to  conduct  missions  and  reduced  Soldiers’  and  Marines’  confidence  in  JBC-P  situational 
awareness  and  enemy  survivability  alerts.  While  Software  Build  6.0  delivered  several  enhanced 
capabilities,  it  introduced  deficiencies  that  significantly  detracted  from  mission  capabilities  and 
led  to  an  assessment  that  the  JBC-P  was  not  effective.  This  is  a  reduction  in  capability  from  the 
November  2013,  JBC-P  Software  Build  5.0  Initial  Operational  Test  and  Evaluation  (IOT&E), 
which  assessed  the  system  as  effective.  Deficiencies  included: 

•  Phantom  Mayday  messages,  which  provided  false  alerts  of  Soldiers  or  units  requiring 
immediate  assistance  during  Network  Integration  Evaluation  (NIE)  14.2.  With  over 
900  occurrences  during  test,  this  is  a  new  JBC-P  deficiency  that  was  not  experienced 
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during  the  JBC-P  Software  Build  5.0  IOT&E.  Despite  two  software  patches  to  fix 
this  problem.  Soldiers  continued  to  experience  phantom  Mayday  messages  during 
NIE  15.1. 

•  Ghost  icons,  which  presented  false  locations  for  blue  forces.  During  Focus  Groups, 
Soldiers  reported  that  ghost  icons  and  phantom  Mayday  messages  reduced  their 
confidence  in  the  information  provided  by  JBC-P. 

•  JBC-P  was  not  effective  in  transmitting  and  receiving  C2  messages.  It  did  not  meet 
user  requirements  for  message  completion  rate  within  the  required  speed  of  service. 

Additionally,  JBC-P  continued  to  demonstrate  deficiencies  during  the  MOT&E  that  were 
observed  during  the  2013  JBC-P  Software  Build  5.0  IOT&E  and  that  continue  to  degrade  user 
confidence  in  the  situational  awareness  information  provided  by  JBC-P.  These  included: 

•  Racing  situational  awareness  icons  that  portrayed  speeds  up  to  200  kilometers  per 
hour  (kph)  during  NIE  14.2,  including  icons  for  both  stationary  units  and  tactical 
ground  forces,  which  normally  should  not  exceed  70  kph.  After  the  program 
attempted  to  fix  this  problem,  Soldiers  experienced  icons  lagging  in  accurate  position 
by  30  minutes  to  one  hour  during  NIE  15.1. 

•  Communications  security  device,  KGV-72,  problems  that  caused  failures. 

•  Map  problems  that  included  incorrect  placement  of  grid  lines,  offset  up  to  1,500 
meters,  and  a  zoom  function  that  slowed  JBC-P  processing,  at  time  locking  up  the 
software. 

JBC-P  Logistics  (JBC-P  Log),  an  integral  component  of  the  JBC-P  Software  Build  6.0, 
did  not  support  the  Anny  brigade’s  logistics  mission.  Soldiers  experienced  a  low  success  rate  in 
interrogating  radio  frequency  identification  (RFID)  tags.  JBC-P  Log  allowed  operators  to  create 
duplicate  RFID  tags  that  portrayed  the  same  cargo  in  different  locations  across  the  brigade. 

JBC-P  served  as  the  brigade’s  tool  for  on-the-move  mission  command,  yet  this  was 
primarily  accomplished  through  the  use  of  chat.  Using  JBC-P,  units  were  able  to  maneuver 
forces  to  key  positions  while  out  of  enemy  contact,  control  the  battle  while  in  contact,  and  rejoin 
forces  upon  completion  of  combat  operations.  JBC-P  supported  the  commander’s  ability  to 
command,  yet  due  to  noted  deficiencies,  commanders  experienced  decreased  confidence  and 
support  from  JBC-P  Software  Build  6.0  compared  to  previous  versions  of  JBC-P  software. 

The  Marine  Corps  participation  in  the  MOT&E  demonstrated  effective  interoperability 
between  the  Marine  Corps  battalion  to  Army  brigade,  and  from  the  Marine  Corps  battalion  to 
Army  battalion  command  echelons. 

Operational  Suitability 

The  Joint  Battle  Command  -  Platform  (JBC-P)  is  not  operationally  suitable.  JBC-P  is  not 
reliable  for  most  versions  of  hardware  hosting  JBC-P  Software  Build  6.0.  JBC-P  meets  the 
user’s  Mean  Time  To  Repair  (MTTR)  maintainability  requirement.  During  the  MOT&E, 
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DOT&E  evaluated  the  reliability,  availability,  and  maintainability  of  major  JBC-P  system 
configurations  employed  by  Army  and  Marine  Corps  units: 

•  Joint  Version  5  (JV5) 

Block  I  Computer  System 
Block  II  Computer  System 

•  Military  Family  of  Computing  Systems  (MFoCS) 

-  MFoCS-Basic  (MFoCS-B) 

-  MFoCS-Intermediate  (MFOCS-I) 

•  Tactical  Operations  Center  (TOC)  Kit 

-  Dell  XFR  TOC 

-  MFoCS-B  TOC 

•  JBC-P  Logistics  (JPC-P  Log) 

-  Military  Rugged  Tablet  -  Plus  (MRT+) 

-  MRT+  Control  Station  (MRT+  CS,  TOC) 

JBC-P  experienced  inconsistent  reliability  across  the  spectrum  of  the  major  JBC-P 
system  configurations.  Some  configurations  performed  well,  but  most  did  not  meet  the  Mean 
Time  Between  Essential  Function  Failure  (MTBEFF)  requirement  of  290  hours.  Fifty-eight 
percent  of  JBC-P  Essential  Function  Failures  were  due  to  software.  With  the  exception  of  the 
JBC-P  Log  MRT+,  all  mobile  JBC-P  systems  met  the  user’s  80  percent  operational  availability 
requirement.  While  the  Marine  Corps  XFR  TOC  system  met  the  requirement,  the  Army’s  use  of 
the  XFR  in  a  TOC  did  not  meet  the  operational  availability  requirement. 

JBC-P  met  the  30-minute  Mean  Time  to  Repair  (MTTR)  requirement  for  all  variants  of 
the  system.  Soldiers  and  Marines  were  able  to  maintain  the  system  because  most  failures  were 
software-related  and  the  crew  could  correct  them  by  rebooting  the  system  without  maintenance 
support.  The  reboot  process  requires  three  steps:  power  down,  power  up,  and  log  in.  The 
average  time  for  a  JBC-P  reboot,  to  include  system  spontaneous  rebooting  during  MOT&E,  was 
eight  minutes. 

JBC-P  training  prepared  Soldiers  and  Marines  to  install  and  operate  their  mobile  and 
TOC  systems.  The  Army  should  consider  improving  the  training  to: 

•  Provide  sufficient  time  for  unit  collective  training. 

•  Increase  hands-on  instruction. 

•  Increase  troubleshooting  instruction  for  maintainers. 

•  Provide  leaders  with  infonnation  tailored  to  their  command  or  staff  position. 

•  Provide  technical  manuals  to  Soldiers  and  Marines. 
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The  JBC-P  Log  training  provided  to  Soldiers  by  the  Army  was  not  effective.  Even  with 
retraining  at  the  beginning  of  record  test,  the  training  provided  did  not  prepare  them  to  operate  or 
maintain  JBC-P  Log. 

The  Army  has  not  developed  a  standard  operating  procedure  (SOP)  for  employing  JBC-P 
within  units  and  integrating  JBC-P  with  other  Army  mission  command  applications  and 
databases.  Signal  Soldiers  across  the  unit  were  challenged  with  the  complexity  of  mission 
command  applications  and  communications,  and  the  unit  was  not  manned  to  accomplish  this 
task.  In  the  case  of  a  logistics  company,  the  unit  was  not  provided  a  signal  Soldier  and  was 
forced  to  train  an  alternate  Soldier  to  perfonn  the  required  communications  tasks.  This  solution 
diverted  a  Soldier  from  their  primary  duties  to  support  JBC-P  and  other  mission  command 
applications. 

Survivability 

JBC-P  is  not  survivable.  The  classified  annex  to  this  report  details  those  deficiencies. 

Recommendations 

The  Army  and  Marine  Corps  should  consider  the  following  actions  to  improve  Joint 
Battle  Command-Platform  (JBC-P)  Software  Build  6.0: 

•  Improve  Effectiveness.  The  Army  should  improve  JBC-P  support  to  unit  mission 
accomplishment  and  demonstrate  the  improvements  in  a  future  operational  test. 

-  Fix  position  location  identification  icon  deficiencies  to  include  false  location, 
lagging,  and  racing  icons. 

-  Correct  unit  command  and  control  alerting,  i.e.  eliminate  phantom  Mayday 
messages. 

-  Improve  shared  survivability  information  to  enable  better  retrieval  and/or  caching 
of  relevant  Entity  Data  Message  map  icons. 

-  Fix  map  deficiencies  to  include  zoom  and  grid  line  accuracy  problems. 

-  Improve  the  performance  of  the  communications  security  device,  KGV-72. 

-  Improve  noted  JBC-P  Log  deficiencies. 

•  Improve  Reliability.  The  Army  should  improve  JBC-P’ s  reliability  and  demonstrate 
improved  reliability  in  an  operational  test  prior  to  full  materiel  release  and  subsequent 
fielding  of  the  JBC-P  Software  Build  6.0. 

-  Identify  and  fix  failure  modes  for  the  MRT+  and  inconsistent  reliability 
performance  for  the  MFoCS  configurations. 

•  Improve  Training.  The  Army  should  improve  JBC-P  New  Equipment  Training. 

-  Provide  JBC-P  collective  training  that  validates  both  individual  and  unit 
proficiency.  Expand  collective  training  to  include  JBC-P  Log. 
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-  Expand  the  leaders’  course  to  provide  more  JBC-P  information  tailored  to  the 
individual  command/staff  position  to  allow  the  full  use  of  its  mission  command 
capabilities. 

-  Expand  the  operators’  course  to  include  more  hands-on  training  and  provide  more 
detail  on  trouble  shooting  beyond  doing  a  system  “reboot.” 

-  Include  training  on  all  JBC-P  components,  e.g.  KGV-72  encryption  device,  to 
enable  Soldiers  to  install,  operate,  and  maintain  the  system. 

•  Create  a  Digital  Standard  Operating  Procedure  (SOP).  The  Army  and  Marine 
Corps  should  create  a  digital  SOP  to  integrate  the  numerous  mission  command 
systems  with  their  services.  This  document  should  standardize  mission  command 
operations  for  both  tactical  operational  centers  and  on-the-move  systems. 

•  Increase  Signal  Soldier  Manning.  The  Army  should  evaluate  manning  of  Signal 
Soldiers,  e.g.  Military  Occupational  Specialty  25U,  across  the  brigade  to  support 
JBC-P  and  other  networked  systems.  The  Army  should  conduct  a  holistic  assessment 
of  mission  command  systems  with  accompanying  communications  systems  and  staff 
their  units  for  mission  success. 

•  Improve  Survivability.  The  Army  should  address  the  deficiencies  and 
recommendations  noted  in  the  classified  annex  of  this  report. 


J.  Michael  Gilmore 
Director 
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Section  One 

System  Overview 


Mission  Description 

The  Joint  Battle  Command  -  Platfonn  (JBC-P)  is  a  networked  mission  command 
information  system  that  enables  Anny  and  Marine  Corps’  units  to  share  near  real-time  friendly, 
enemy,  and  battlefield  situational  awareness,  operational  maps  and  graphics,  and  command  and 
control  (C2)  messages.  The  Army  and  Marine  Corps  intend  JBC-P  to  provide  joint,  platform- 
level  interoperability  for  operations  centers,  ground  vehicles,  aviation  assets,  and  dismounted 
Soldier/Marine  platforms  operating  in  land/littoral-dominated  joint  battle  space.  JBC-P  expands 
upon  the  previously  released  Force  XXI  Battle  Command  Brigade  and  Below  (FBCB2)  and 
FBCB2-Joint  Capability  Release  (FBCB2-JCR)  systems  and  is  designed  to  provide: 

•  Blue  (friendly)  situational  awareness 

•  Red  (enemy)  situational  awareness 

•  Network  integration 

•  Sustainment 

The  Army  and  Marine  Corps  intend  the  JBC-P  Battle  Command  Product  Line  to  provide 
the  following  critical  battlefield  capabilities  to  vehicle  platforms  and  dismounted 
Soldiers/Marines: 

•  Improved  Combat  Identification  at  the  point  of  engagement  to  reduce  fratricide 

•  Improved  on-the-move  situational  awareness  through  a  rapidly  updated  common 
picture  of  the  battlefield 

•  Enhanced  Mission  Command  or  C2  capability  over  extended  tactical  and  operational 
distances 

•  More  accurate  position  locations  of  friendly  units,  combined  with  network  wide 
dissemination  of  reported  enemy,  neutral  entities,  unknown  entities,  and  terrain 
information 

Commanders  use  JBC-P’s  situational  awareness  to  maneuver  forces  to  positions  of 
battlefield  advantage  based  upon  knowledge  of  friendly  and  enemy  forces.  Commanders  and 
Soldiers/Marines  should  experience  improved  support  of  maneuver  units  through  enhanced 
situational  awareness  and  messaging,  which  provides  numerous  benefits  including  greater 
survivability,  more  effective  link-up  of  medical  and  vehicle  recovery  assets,  and  efficient 
resupply.  Commanders  and  staff  use  JBC-P  to  conduct  mission  command  through  the  exchange 
of  orders  and  graphics  via  horizontal  and  vertical  communications  between  combat  vehicles  and 
the  Tactical  Operations  Centers  (TOCs) 

The  Army  uses  JBC-P  Logistics  (JBC-P  Log)  to  support  unit  mission  logistics  from 
select  Army  JBC-P  Software  Build  6.0  systems.  JBC-P  Log  enables  the  transfer  of  blue  force 
and  threat  data  between  maneuver,  maneuver  support,  and  sustainment  systems.  Soldiers  using 


1 


JBC-P  Log  can  identify,  track,  and  re-route  cargo  vehicles  as  required  to  support  the 
commander’s  mission  execution. 

Incremental  Development 

The  Army  established  JBC-P  as  an  incremental  development  program  with  a  series  of 
software  builds  that  increase  in  capability  to  complete  the  104  threshold  requirements  contained 
within  the  approved  JBC-P  Capabilities  Development  Document  (CDD).  On  March  15,  2013, 
the  Joint  Requirements  Oversight  Committee  approved  the  JBC-P  CDD  (used  in  lieu  of  a 
Capabilities  Production  Document).  To  define  its  increment  build  strategy,  the  Anny  G3/5/7 
published  a  memorandum  in  May  2013  outlining  the  JBC-P  CDD  requirements  to  be  satisfied  by 
JBC-P  Software  Build  5.0  and  follow-on  versions. 

In  May  2013,  the  Anny  conducted  a  JBC-P  Software  Build  5.0  Initial  Operational  Test 
and  Evaluation  (IOT&E)  in  accordance  with  a  DOT&E-approved  test  plan.  The  IOT&E  was 
conducted  in  conjunction  with  the  Anny’s  Network  Integration  Evaluation  (NIE)  13.2  in  May 
2013.  DOT&E  published  an  IOT&E  report  on  JBC-P  on  November  22,  2013,  which  assessed 
JBC-P  as  operationally  effective  in  supporting  Army  commanders  and  Soldiers  with  situational 
awareness,  command  and  control  (C2)  messages,  and  chat  when  operating  from  Tactical 
Operational  Centers  (TOCs)  and  on-the-move  in  tactical  vehicles.  The  report  found  that  JBC-P 
was  operationally  effective  in  supporting  the  unit's  mission  success  and  mission  utility  during  all 
24  missions  conducted  during  the  IOT&E.  The  report  noted  that  poor  reliability  due  to  frequent 
outages  and  software  problems  hampered  operational  effectiveness.  The  assessment  found  that 
JBC-P  was  not  operationally  suitable  due  to  substantive  reliability  issues.  The  report  also  found 
that  JBC-P  was  not  survivable,  as  it  had  significant  cybersecurity  vulnerabilities  that  would  place 
a  unit's  ability  to  succeed  in  combat  at  risk. 

Following  operational  test,  the  Army  developed  JBC-P  Software  Build  5.1,  which 
addressed  deficiencies  noted  during  the  IOT&E,  and  was  intended  to  satisfy  the  CDD’s  four  Key 
Performance  Parameters  (KPPs)  and  over  60  percent  of  the  threshold  requirements.  Based  upon 
successful  program  regression  testing,  the  Army  approved  a  fielding  decision  for  JBC-P 
Software  Build  5. 1  in  November  2013. 

The  Army  updated  the  JBC-P  incremental  build  memo  in  March  2014  to  define 
capabilities  to  be  delivered  in  Software  Build  6.0  for  assessment  during  the  May  2014  JBC-P 
Multi-Service  Operational  Test  and  Evaluation  (MOT&E),  which  was  conducted  in  conjunction 
with  NIE  14.2.  The  Army  intends  for  Software  Build  6.0  to  satisfy  the  JBC-P  CDD’s  KPPs  and 
90  percent  of  threshold  requirements.  The  Marine  Corps  published  a  memorandum  that 
concurred  with  the  Army’s  definition  of  required  capabilities  within  JBC-P  Software  Build  6.0. 

The  new  capabilities  provided  by  JBC-P  Software  Build  6.0  include: 

•  JBC-P  Log  with  Radio  Frequency  Identification  (RFID)  tag  interrogation,  and 
reporting  and  message  exchange  with  the  Battle  Command  Sustainment  Support 
System  (BCS3).  The  JBC-P  Log  provides  logistics  information  to  the  Transportation 
Coordinator’s  Automated  Information  for  Movement  System  II  ( TC-AIMS II)  and  the 
Global  Combat  Support  System  (GCSS)  to  enhance  Army  total  asset  visibility. 
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•  Area  Structures,  Capabilities,  Organizations,  People,  and  Events  (ASCOPE)  reports 
and  collections,  to  include  search-along-route  function. 

•  Transfer  of  digital  pictures  from  dismounted  Soldiers  using  Nett  Warrior. 

•  Sharing  of  Global  Positioning  System  (GPS)  information  within  the  combat  vehicle 
or  tactical  operations  center. 

•  Hybrid  Capability  -  the  ability  of  the  JBC-P  system  to  employ  both  celestial  and 
terrestrial  networks  for  exchanging  mission  command  information. 

System  Description  and  Capabilities 

JBC-P  Software  Build  6.0  provides  the  following  functional  capabilities  as  tested  during 
the  Network  Integration  Evaluation  14.2  JBC-P  MOT&E: 

•  Graphical  User  Interface  (GUI)  -  The  GUI  provides  JBC-P’ s  output  display  and 
user  input  tools  to  include  keyboard  and  touch  screen  capabilities  (Figure  1-1).  The 
GUI  is  an  enhancement  of  the  fielded  FBCB2-JCR,  and  includes  improved  map 
functions,  graphics,  images,  and  the  ability  to  display  ASCOPE  data.  The  GUI 
allows  Soldiers  and  Marines  to  add  overlays  and  icons  to  enhance  the  situational 
awareness,  and  use  chat  capability  and  messaging  to  support  mission  command. 


FIPR  =  Flash/Immediate/Priority/Routine  precedence  description. 

Figure  1-1.  JBC-P  Graphical  User  Interface  map  display. 

•  Chat  -  Tactical  chat  and  chat  room  capability  provides  enhanced  collaboration  for 
commanders.  Chat  allows  leaders  to  conduct  planning,  assist  in  orders  development, 
execute  missions,  and  decrease  overall  mission  coordination  time. 
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Figure  1-2.  JBC-P  Graphical  User  Interface  with  inset  chat  window. 

•  Network  Services  Gateway  (NSG)  -  The  NSG  is  an  additional  capability  introduced 
with  the  JBC-P  software  to  fill  beyond-line-of-sight  communications  shortfalls  within 
the  battlefield  environment.  The  NSG  uses  an  internet  protocol  (IP)  interface  within  a 
standard  JBC-P  computer  to  connect  to  the  lower  tactical  internet.  The  transfer  of  C2 
and  situational  awareness  messages  can  be  accomplished  using  standard  military- 
approved  IP-based  waveforms  (e.g.  the  Soldier  Radio  Waveform  or  Highband 
Networking  Waveform)  to  connect  JBC-P  to  dismounted  Soldiers  or  adjacent 
vehicles  by  terrestrial  radio. 

•  Tactical  Ground  Reporting  (TIGR)  -  TIGR  stores,  maintains,  and  synchronizes 
ASCOPE  data  between  the  TOC  and  tactical  vehicles. 

•  Map  Engine  -  JBC-P’s  map  engine  provides  an  improvement  upon  the  fielded 
FBCB2-JCR  for  the  display  of  tactical  maps  and  images. 

•  Information  Exchange  -  JBC-P  provides  blue  force  situational  awareness  updates 
via  automatic  (operator  independent)  maps,  graphics,  and  overlays  to  tactical  vehicles 
and  TOCs.  This  includes  all  units  equipped  with  JBC-P,  FBCB2-JCR,  FBCB2,  and 
Nett  Warrior-equipped  dismounted  Soldiers  connected  to  the  JBC-P  network.  JBC-P 
provides  tools  for  users  to  add  shared  graphics  and  overlays  for  known  enemy 
locations. 

•  Hybrid  Network  Capability  -  The  hybrid  network  capability  provides  alternate  and 
redundant  means  of  communications  on  an  intelligent  basis  between  terrestrial  and 
celestial  transport  layers.  By  monitoring  the  quality  of  its  satellite  network,  the  JBC- 
P  Hybrid  Network  Capability  is  designed  to  automatically  select  the  best  means  of 
communications  (celestial  or  terrestrial),  which  increases  network  robustness  during 
mission  operations. 

•  JBC-P  Log  Capability-  JBC-P  Log  provides  RFID  tag  interrogation,  reporting,  and 
message  exchange.  JBC-P  Log  reports  RFID  data  exchanges  to  the  JBC-P  Network 
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Operations  Center,  where  it  is  shared  with  other  Army  logistics  systems  via  the 
Movements  Tracking  System-Enhanced  Software  (MTS-ES).  This  exchange  allows 
logisticians  to  track  the  worldwide  location  of  cargoes  and  equipment  in  near-real 
time. 

The  Army  and  Marine  Corps  host  JBC-P  Software  Build  6.0  on  several  different 
computer  systems  with  supporting  hardware.  During  MOT&E,  Soldiers  and  Marines  employed 
the  computer  systems  and  hardware  described  in  the  paragraphs  below.  Note,  the  first  six 
paragraphs  describe  host  computers  while  the  remaining  items  and  software  support  JBC-P 
operations. 

Mounted  Refresh  Computer  (MRC) 

The  Marine  Corps  MRC  (Figure  1-3)  supports  both  vehicle-mounted  (left  side  of  figure) 
and  TOC  kit  (right  side  of  figure)  operations.  The  mounted  systems  are  fielded  in  both  terrestrial 
and  celestial  configurations. 


12’  Standard  Qsplay  II  Ji  f  _l-%  10‘ MRC-DU 


Figure  1-3.  Marine  Corps  Mounted  Refresh  Computer 


Joint  Tactical  Common  Operational  Picture  (COP)  Workstation  (JTCW) 

The  JTCW  (Figure  1-4)  is  a  windows-based  suite  of  applications  designed  to  provide 
Marine  Corps  battalion  and  above  echelons  with  command  and  control  functions,  improved 
situational  awareness  and  enhanced  operational  and  tactical  decision-making.  The  JTCW  serves 
as  the  COP  interface  between  the  JBC-P  and  Marine  Corps  workstations  at  battalion  and  above. 
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Figure  1-4.  Dell  XFR  computers  hosting  the  JTCW  suite  of  applications  in  a  Marine  Corps  command  post 

Joint  Version  5  (JV5)  Block  1  and  JV5  Block  2  Computers 

The  JV5  Block  1  and  JV5  Block  2  (Figures  1-5  and  1-6)  are  JBC-P  host  computer 
systems  with  display  units.  The  JV5  Block  2  is  an  upgrade  of  the  JV5  Block  1  that  provides  a 
faster  computer  processing  unit,  increased  Random  Access  Memory  (RAM)  and  hard  disk 
storage,  and  improved  graphics. 


Figure  1-5.  JBC-P  JV5  Block  2  display  Figure  1-6.  Commander  using  a  JBC-P  JV5 

and  keyboard  Block  2  on  a  Multi-Domain  Atlas  display 

Mounted  Family  of  Computing  Systems  (MFoCS)  -Basic  and  Intermediate 

The  MFoCS  (Figure  1-7)  is  the  Army’s  computer  hardware  upgrade  for  the  JV5  Block  1 
and  JV5  Block  2  computers.  MFoCS  includes  advanced  computing  technologies  with  improved 
processing  capability  to  include  high-definition  graphics,  higher-capacity  hard  drives,  and 
additional  memory.  The  MFoCS  consists  of  three  configurations  -  MFoCS  Basic  (TOC 
systems);  MFoCS  Basic  and  Intermediate  (vehicle-mounted  systems),  and  MFoCS  Advanced 
(user  or  mission  dictates  this  higher  capability).  These  three  systems  consist  of  common  line 
replaceable  units  and  are  compatible  with  existing  JV5  installation  kits,  keyboards,  and  displays. 
MFoCS’  modularity  of  design  enables  Soldiers  to  configure  their  systems  for  specific 
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applications  (i.e.,  JBC-P,  JBC-P  Log,  TIGR,  Command  Post  of  the  Future,  Distributed  Common 
Ground  System  -  Army,  Advanced  Field  Artillery  Tactical  Data  System)  based  upon  mission 
needs. 


Basic 


Intermediate 


KU  =  Keyboard  Unit 
PU  =  Processor  Unit 
DU  =  Display  Unit 


Figure  1-7.  Mounted  Family  of  Computing  Systems  used  in  JBC-P. 


Tactical  Operations  Center  (TOC)  Kit  -  Dell  XFR  Computer 

TOC  Kits  (Figure  1-8)  provide  JBC-P  mission  command  and  situational  awareness  to 
commanders  within  command  posts.  A  TOC  kit  consists  of  a  Dell  XFR  laptop  hosting  JBC-P 
software,  a  Defense  Advance  GPS  Receiver  (DAGR),  a  Blue  Force  Tracker  2  (BFT2)  satellite 
transceiver,  and  a  KGV-72  encryption  device  (see  following  paragraphs  for  descriptions).  The 
Marine  Corps  TOC  kit  is  identical  to  the  Army  version. 


Figure  1-8.  JBC-P  TOC  Kit 


Military  Rugged  Tablet  -  Plus  (MRT+) 

The  MRT+  (Figure  1-9)  is  a  ruggedized  computer  tablet  that  supports  the  functions  of 
JBC-P  Log  within  an  Army  TOC.  The  MRT+  provides  computer  processing  capabilities  in  a 
compact  form  and  uses  a  10.4”  display. 
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Figure  1-9.  Military  Rugged  Tablet  -  Plus 

Blue  Force  Tracker  (BFT)  2  Transceiver 

JBC-P  uses  an  L-band  satellite  (950-2150  Megahertz  (MHz))  transceiver  (see 
Figure  1-10)  to  support  a  shared  80  to  90  kilobits  per  second  (kbps)  data  uplink  and  downlink 
within  its  supporting  satellite  footprint.  BFT2’s  increased  throughput  (over  the  earlier  BFT1) 
allows  JBC-P  to  receive  more  frequent  updates  and  provide  more  accurate  situational  awareness 
for  Soldiers  and  Marines.  The  Army  plans  to  field  a  BFT2  transceiver  with  each  vehicle  and 
fixed  location  JBC-P.  The  Marine  Corps  intends  to  field  a  mix  of  BFT2  and  terrestrial  radios  to 
support  JBC-P. 


Figure  1-10.  Blue  Force  Tracker  Satellite  Transceiver 


KGV-72  Type  I  Programmable  In-Line  Encryption  Device 

The  KGV-72  (Figure  1-11)  provides  communications  data  encryption  and  ensures  that 
BFT2  transmissions  are  certified  to  support  Secret  transmissions  for  JBC-P,  FBCB2-JCR,  and 
FBCB2. 
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Figure  1-11.  (Left)  KGV-  72  Type  1  Programmable  In-Line  Encryption  Device  and 
(Right)  a  KGV-72  (with  lock,  above,  front,  left)  located  above  front  left  of  a  platoon  leader. 


Defense  Advanced  Global  Positioning  System  (GPS)  Receiver  (DAGR) 

The  DAGR  (Figure  1-12)  is  a  handheld  GPS  receiver  that  serves  as  a  component  of  the 
JBC-P  vehicle  and  TOC  systems.  It  is  a  military-grade,  dual-frequency  receiver,  and  maintains 
the  security  hardware  necessary  to  decode  military  band,  encrypted  P(Y)-code  GPS  signals. 


Figure  1-12.  Company  Commander  using  the  JBC-P  with  DAGR 
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BFT2  with  RFID  Interrogator 

The  BFT2  transceiver  coupled  with  an  RFID  interrogator  (Figure  1-13)  allows  JBC-P 
Log  to  use  wireless  transfer  of  data  to  enable  automatic  identification  and  tracking  of  RFID  tags 
attached  to  objects  and  cargoes. 


Figure  1-13.  BFT  transceiver  with  the  RFID  interrogator  in  the  top  left  corner. 

Network  Operations  Center  (NOC) 

The  JBC-P  Network  Operations  Center  (NOC)  (Figure  1-14)  provides  the  central  routing 
capability  for  the  JBC-P  system.  The  NOC  provides  the  network  interface  between  celestial 
(satellite)  and  terrestrial  (radio)  based  platforms  in  the  FBCB2-JCR  and  JBC-P  networks.  The 
NOC  receives  transmitted  information  and  re-broadcasts  it  to  worldwide  recipient  systems  in 
combat  vehicles  and  command  posts.  The  JBC-P  system  cannot  function  without  the  central 
routing  provided  by  the  NOC. 


Figure  1-14.  JBC-P  Network  Operations  Center 
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Section  Two 

Test  Adequacy 


Operational  Testing 

The  Multi-Service  Operational  Test  and  Evaluation  (MOT&E)  of  the  Joint  Battle 
Command  -  Platform  (JBC-P)  Software  Build  6.0  was  adequate  to  assess  JBC-P  operational 
effectiveness,  suitability,  and  survivability.  The  Army  Test  and  Evaluation  Command  (ATEC) 
conducted  the  operational  test  in  accordance  with  a  DOT&E-approved  test  plan  to  support  the 
following  proposed  JBC-P  Software  Build  6.0  decisions: 

•  1QFY15  Army  materiel  release  decision 

•  2QFY15  Marine  Corps  fielding  decision 

The  Army  approved  a  fielding  decision  for  JBC-P  Software  Build  5. 1  in  November  2013  based 
upon  a  May  2013  JBC-P  Initial  Operational  Test  and  Evaluation  (IOT&E)  and  subsequent 
program  regression  testing. 

ATEC  conducted  the  JBC-P  MOT&E  from  April  28  through  May  17,  2014,  as  part  of  the 
Army’s  Network  Integration  Evaluation  (NIE)  14.2  at  Fort  Bliss,  Texas.  At  NIE  15.1,  October 
15  through  November  2,  2014,  ATEC  conducted  surveys  and  interviews  to  assess  software  fixes 
of  deficiencies  noted  during  MOT&E. 

The  JBC-P  system  with  Software  Build  6.0  is  projected  for  fielding  as  part  of  the  Army’s 
Capability  Set  15.  JBC-P  is  an  Acquisition  Category  II  program  with  DOT&E  oversight.  The 
MOT&E  included  the  JBC-P  and  Force  XXI  Battle  Command  Brigade  and  Below  (FBCB2) 

Joint  Capability  Release  (JCR)  Network  Operations  Centers  (NOCs)  at  Aberdeen  Proving 
Ground,  Maryland.  This  evaluation  is  based  upon  the  JBC-P  MOT&E  supplemented  by  prior 
developmental  testing  that  occurred  during  the  JBC-P  Risk  Reduction  Event  14,  Government 
Developmental  Test,  and  Regression  Test.  The  developmental  and  operational  test  dates  and  the 
events  that  led  up  to  the  MOT&E  appear  in  Table  2-1. 


Table  2-1.  Test  Schedule 


Activity 

Date 

New  Equipment  Training 

February  3  -  March  28,  2014 

Step  4,  Operational  Information  Assurance/Cyber 
Security  Vulnerability  Evaluation 

March  10- April  4,  3014 

Pilot  Test 

April  28 -May  2,  2014 

Record  Test 

May  6-17,  2014 

Regression  Testing  of  Fixes  and  Survey/Interviews 
with  Soldiers 

October  15-Novermber  2,  2014 

The  MOT&E  provided  adequate  data  to  assess  the  effectiveness  of  the  JBC-P.  The  Army 
installed  instrumentation  to  collect  data  on  sent  and  received  situational  awareness  and  command 
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and  control  (C2)  messages,  and  installed  military  data  collectors  in  vehicles  and  facilities.  There 
were  a  total  of  282  JBC-P  systems  in  the  NIE.  Of  these,  there  were  63  JBC-P  systems  (56  Army 
and  7  Marine  Corps)  operating  in  combat  vehicles  and  TOCs  that  were  instrumented  to  capture 
situational  awareness  messages,  C2  messages,  and  survivability  messages. 

The  test  unit,  2nd  Brigade,  1st  Armored  Division  (2-1  AD),  at  Fort  Bliss/White  Sands 
Missile  Range,  is  a  heavy  brigade  combat  team  that  provided  a  brigade  headquarters  and  six 
battalions  to  perform  missions  under  operationally  realistic  conditions.  The  brigade  employed  a 
mix  of  JBC-P,  FBCB2  JCR,  and  FBCB2  Version  6.5  systems  to  provide  the  unit’s  situational 
awareness,  chat,  and  C2  messaging.  Within  this  combined  network,  the  brigade  deployed  56 
instrumented  JBC-P  systems  in  the  Brigade  Headquarters,  the  4th  Battalion,  17th  Infantry  (4-17 
IN);  the  1st  Squadron,  1st  Cavalry  Regiment  (1-1  CAV);  and  the  47th  Brigade  Support  Battalion 
(47  BSB).  The  NOC  at  Aberdeen  Proving  Ground,  Maryland,  is  a  fixed  facility  that  provides 
worldwide  support  and  interoperability  of  JBC-P,  FBCB2  JCR,  and  FBCB2  Version  6.5 
networks  under  operational,  training,  and  testing  environments.  For  MOT&E,  a  test/training 
NOC,  operating  alongside  the  real-world  NOC,  maintained  two  instrumented  systems. 

The  Marine  Corps  unit,  2-8th  Infantry  Battalion  (2-8  Marines),  was  attached  to  the  Army 
brigade  and  employed  seven  instrumented  JBC-P  systems.  The  2-8th  employed  three 
instrumented  infantry  company  combat  vehicles  equipped  with  terrestrial-capable  JBC-P  systems 
and  four  instrumented  weapons  company  celestial-capable  JBC-P  systems.  The  MOT&E  Army 
and  Marine  Corps  test  units  conducted  operationally  realistic  scenarios  to  include  offensive, 
defensive,  and  stability  missions  employed  at-the-halt  and  on-the-move. 

The  Army  and  Marine  Corps  embedded  military  data  collectors  in  79  combat  vehicles,  2 
NOCs,  3  Tactical  Operations  Centers  (TOCs),  and  2  Military  Rugged  Tablet  Control  Stations  to 
capture  reliability  data  and  document  these  in  Test  Incident  Reports.  Following  test  completion, 
ATEC  recognized  from  the  duty  logs  that  data  collectors  had  not  provided  all  test  incidents  for 
the  reliability  evaluation.  ATEC  reassessed  the  data  logs  compared  to  instrumented  data  to 
create  a  complete  reliability  assessment. 

The  MOT&E  instrumented  and  collected  data  on  six  TOCs  (3  Dell  XFRs  and  3  Mounted 
Family  of  Computing  Systems-Basic)  and  the  JBC-P/JCR  test  NOCs.  Due  to  the  low  density  of 
these  systems,  data  collection  yielded  insufficient  operating  hours  for  a  meaningful  reliability 
assessment. 

The  MOT&E  was  adequate  to  address  the  joint  interoperability  between  the  Army  and 
Marines  in  an  integrated  scenario  with  an  Army  brigade  and  elements  of  a  Marine  Corps 
Regiment  engaged  in  joint  operational  scenarios. 

The  MOT&E  collected  manual  data  to  include  a  blue  ribbon  panel  for  mission 
effectiveness  assessment,  mission  interviews,  video-recorded  focus  groups,  test  participant 
structured  interviews,  test  team  observations,  and  subject  matter  expert  comments. 

Test  Scenario 

The  JBC-P  Operational  Mode  Summary/Mission  Profile  (OMS/MP)  focuses  on  a  single 
Wartime  Mission  Profile,  72-  hour  Major  Combat  Operations  (MCO),  for  selected  combat 
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platforms  within,  or  in  direct  support  of,  the  Heavy  Brigade  Combat  Team  (HBCT).  The  MCO 
represents  the  most  strenuous  profile  for  Unified  Land  Operations  during  which  combat 
operations  are  conducted  by  all  HBCT  echelons.  The  MOT&E  stressed  Army  and  Marine  Corps 
JBC-P  systems  within  the  brigade  during  a  12-day  operational  test,  which  included  realistic 
missions  and  scenarios.  The  1-1  CAV  was  the  primary  unit  under  test,  operating  as  a  cavalry 
unit,  performing  screen  and  reconnaissance  missions,  and  conducting  limited  attacks.  The  4-17 
IN  employed  JBC-P  systems  and  conducted  appropriate  missions.  Between  these  two  units,  the 
MOT&E  collected  sufficient  data  to  assess  mission  performance.  The  test  units  executed 
decisive  action  operations  that  included  offensive,  defensive,  and  stability  missions  employed 
at-the-halt  and  on-the-move.  The  2-8  Marines  were  under  the  operational  control  of  the  2-1 
Brigade  and  conducted  appropriate  missions.  The  47  BSB  conducted  operational  missions  to 
assess  JBC-P  Log  capabilities.  The  Brigade  Modernization  Command  served  as  the  division 
headquarters  and  issued  warning  orders,  fragmentary  orders,  and  operations  orders  to  transition 
the  test  through  scenario  phases.  ATEC  designed  each  phase  in  accordance  with  the 
requirements  of  the  72-hour  OMS/MP. 

Unit  Task  Reorganization  (UTR)  is  a  core  JBC-P  function  and  is  planned  by  the  brigade 
commander  or  S-3  and  executed  by  the  S-6.  The  Brigade  executed  14  UTRs  at  the  platoon, 
company,  battalion,  and  regiment  echelons,  including  cross-Service  UTRs  (i.e.,  Anny  to  Army 
and  Army  to  Marine  Corps  and  vice  versa): 

•  2-8  Marines  into  (and  back  out  of)  the  2-1  AD 

•  F  Company,  2-8  Marines  into  (and  back  out  of)  1-6  IN 

•  C  Troop,  1-1  CAV  into  (and  back  out  of)  4-17  IN 

•  D  Company,  1-6  IN  and  1-1  CAV  into  (and  back  out  of)  2-8  Marines 
Information  Assurance 

Prior  to  and  during  the  MOT&E,  the  Army  Research  Laboratory  Survivability/Lethality 
Analysis  Directorate  (ARL/SLAD)  conducted  Information  Assurance  assessments  on  JBC-P  that 
included: 

•  Step  4  -  Operational  Information  Assurance  Vulnerability  Evaluation 

•  Step  5  -  Protect,  Detect,  React,  and  Restore  Evaluation 

These  tests  were  performed  in  accordance  with  the  DOT&E  memorandum  “Procedures  for 
Operational  Test  and  Evaluation  of  Information  Assurance  in  Acquisition  Programs,”  dated 
January  21,  2009,  and  included  clarifications  and  improvements  published  in  November  2010 
and  February  2013. 

Electronic  Warfare 

During  the  MOT&E,  electronic  warfare  testing  consisted  of  open-air  jamming  and 
direction  finding  operations.  The  Threat  Systems  Management  Office  provided  and  operated  the 
jamming,  direction  finding,  and  GPS-imitating  equipment  to  support  the  multiple  72-hour 
scenarios  in  an  electronic  warfare  environment.  All  threats  portrayed  were  in  accordance  with 
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the  accredited  threat  for  JBC-P.  Electronic  warfare  was  focused  on  Marine  Corps  units,  since  the 
Army  units  received  an  electronic  warfare  assessment  during  the  NIE  13.2  JBC-P  IOT&E. 

System  Support 

Field  Service  Representatives  (FSRs)  participated  in  the  MOT&E  as  sustainment-level 
maintenance.  FSR  support  of  the  operation  and  maintenance  during  the  JBC-P  MOT&E  was  in 
accordance  with  the  maintenance  support  concept  for  a  heavy  brigade  combat  team.  The  Army 
program  office  provided  two  FSRs  for  the  JBC-P  MOT&E,  one  to  service  the  battalions  and  one 
at  brigade. 

Net  Ready  Key  Performance  Parameter 

The  Army  and  Marine  Corps  tested  JBC-P  Software  Build  6.0  to  assess  the  Net  Ready 
Key  Perfonnance  Parameter.  The  JBC-P  MOT&E  assessed  JBC-P  for  backward  compatibility 
with  FBCB2  versions  6.5  and  JCR,  as  well  as  interoperability  with  the  Marine  Corps. 

Joint  Interoperability  Certification  (JIC)  and  Anny  Interoperability  Certification  (AIC) 
are  required  to  ensure  the  system  meets  approved  technical  standards  and  information  exchange 
requirements,  and  does  not  introduce  vulnerabilities  or  reduce  service  when  connected  to  active 
networks.  The  Joint  Interoperability  Test  Command  assessed  JBC-P  Software  Build  6.0  for  JIC 
during  the  JBC-P  MOT&E.  The  Army  completed  the  JBC-P  Software  Build  6.0  AIC  during 
3/4QFY 14  to  meet  the  requirements  of  the  Net  Ready  Key  Performance  Parameter.  The  AIC 
will  also  assess  compliance  of  the  JBC-P  software  message  set  to  Military  Standard  6017A, 
which  is  the  Department  of  Defense  standard  for  Variable  Message  Format  (YMF)  messages. 
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Section  Three 

Effectiveness 

The  Joint  Battle  Command  -  Platform  (JBC-P)  Software  Build  6.0  is  not  operationally 
effective.  It  did  not  demonstrate  the  ability  to  support  Army  and  Marine  Corps  leaders,  Soldiers, 
and  Marines  with  the  user’s  requirements  for  Command  and  Control  (C2)  messages,  and 
Survivability/Entity  Data  messages  when  operating  from  Tactical  Operational  Centers  (TOCs) 
and  on-the-move  in  tactical  vehicles.  Several  JBC-P  software  deficiencies  reduced  the  units’ 
ability  to  conduct  missions  and  reduced  Soldiers’  and  Marines’  confidence  in  JBC-P  situational 
awareness  and  enemy  survivability  alerts.  While  Software  Build  6.0  delivered  several  enhanced 
capabilities,  it  introduced  deficiencies  that  significantly  detracted  from  mission  capabilities  and 
led  to  an  assessment  that  the  JBC-P  was  not  effective.  This  is  a  reduction  in  capability  from  the 
November  2013,  JBC-P  Software  Build  5.0  Initial  Operational  Test  and  Evaluation  (IOT&E), 
which  assessed  the  system  as  effective.  These  deficiencies  included: 

•  Phantom  Mayday  messages,  which  provided  false  alerts  of  Soldiers  or  units  requiring 
immediate  assistance  during  Network  Integration  Evaluation  (NIE)  14.2.  With  over 
900  occurrences  during  the  JBC-P  Software  Build  6.0  Multi-Service  Operational  Test 
and  Evaluation  (MOT&E),  this  is  a  new  JBC-P  deficiency  that  was  not  experienced 
during  the  JBC-P  IOT&E.  Despite  two  software  patches  to  fix  this  problem,  Soldiers 
continued  to  experience  phantom  Mayday  messages  during  the  subsequent  NIE  15.1. 

•  Ghost  icons,  which  presented  false  locations  for  blue  forces.  During  Focus  Groups, 
Soldiers  reported  that  ghost  icons  and  phantom  Mayday  messages  reduced  their 
confidence  in  the  information  provided  by  JBC-P. 

•  JBC-P  was  not  effective  in  transmitting  and  receiving  C2  messages.  It  did  not  meet 
user  requirements  for  message  completion  rate  within  the  required  speed  of  service. 

Additionally,  JBC-P  continued  to  demonstrate  deficiencies  during  MOT&E  that  were  observed 
during  the  2013  JBC-P  IOT&E  and  that  continue  to  degrade  user  confidence  in  the  situational 
awareness  information  provided  by  JBC-P.  These  included: 

•  Racing  situational  awareness  icons  that  portrayed  speeds  up  to  200  kilometers  per 
hour  (kph)  during  the  JBC-P  MOT&E,  including  icons  for  both  stationary  units  and 
tactical  ground  forces,  which  normally  should  not  exceed  70  kph.  After  the  program 
attempted  to  fix  this  problem.  Soldiers  experienced  icons  lagging  in  accurate  position 
location  by  30  minutes  to  one  hour  during  NIE  15.1. 

•  Communications  security  device,  KGV-72,  problems  that  caused  failures. 

•  Map  problems  that  included  incorrect  placement  of  grid  lines,  offset  up  to  1,500 
meters,  and  a  zoom  function  that  slowed  JBC-P  processing,  at  time  locking  up  the 
software. 

JBC-P  Logistics  (JBC-P  Log),  an  integral  component  of  the  JBC-P  Software  Build  6.0, 
did  not  support  the  Anny  brigade’s  logistics  mission.  Soldiers  experienced  a  low  success  rate  in 
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interrogating  radio  frequency  identification  (RFID)  tags,  and  JBC-P  Log  allowed  operators  to 
create  duplicate  RFID  tags  that  portrayed  the  same  cargo  in  different  locations  across  the 
brigade.  JBC-P  Log  software  is  not  mature,  and  the  identified  problems  distracted  from  the 
unit’s  logistics  mission. 

JBC-P  served  as  the  brigade’s  tool  for  on-the-move  mission  command,  yet  this  was 
primarily  accomplished  through  the  use  of  chat,  a  legacy  capability.  Using  JBC-P,  units  were 
able  to  maneuver  forces  to  key  positions  while  out  of  enemy  contact,  control  the  battle  while  in 
contact,  and  rejoin  forces  upon  completion  of  combat  operations.  JBC-P  supported  the 
commander’s  ability  to  command,  yet  due  to  noted  deficiencies,  commanders  experienced 
decreased  confidence  and  support  from  JBC-P  Software  Build  6.0  compared  to  previous  versions 
of  JBC-P  software. 

JBC-P  met  technical  requirements  for  the  timely  transfer  of  position  location  infonnation. 
Nonetheless,  the  MOT&E  highlighted  serious  deficiencies  in  situational  awareness  which 
included  racing  icons,  inaccurate  position  location,  and  phantom  Mayday  messages  that  caused 
Soldiers  to  lose  confidence  in  the  system.  The  unit’s  lack  of  confidence  in  JBC-P  situational 
awareness  forced  Soldiers  to  confirm  blue  force  locations  through  the  use  of  alternate 
communications  such  as  chat  and  combat  net  radio. 

As  stated,  JBC-P  was  not  effective  in  transmitting  and  receiving  C2  messages.  It  did  not 
meet  user  requirements  for  message  completion  rate  within  the  required  speed  of  service.  The 
JBC-P  chat  capability  supported  commanders  in  the  planning  and  execution  of  missions.  Chat 
provided  leaders  the  ability  to  execute  mission  command  across  all  levels  within  the  brigade. 
Although  improved  since  the  JBC-P  IOT&E,  poor  reliability  due  to  frequent  outages  and 
software  problems  continued  to  hamper  operational  effectiveness.  The  Marine  Corps 
participated  as  an  attached  unit  in  the  MOT&E,  and  JBC-P  demonstrated  the  capability  to 
operate  in  the  joint  operational  environment  as  described  in  the  user’s  requirement  Key 
Performance  Parameter. 

Shared  Blue  Situational  Awareness 

JBC-P  exceeded  the  user’s  technical  requirements  (primarily,  timeliness  of  message 
transmission)  for  the  display  of  friendly  force  situational  awareness  for  leaders  and 
Soldiers/Marines  on-the-move  and  at-the-halt.  Although  JBC-P  met  the  user’s  requirements, 
Soldiers  and  Marines  experienced  decreased  confidence  in  the  provided  situational  awareness 
due  to  racing  icons,  inaccurate  position  location,  and  phantom  Mayday  messages  (which 
generated  false  icons);  thus,  although  timely,  situational  awareness  was  inaccurate.  Table  3-1 
shows  the  friendly  or  blue  force  visibility.  Visibility  rates  show  the  percentage  of  situational 
awareness  information  received  within  a  time  and  distance  set  by  the  user’s  requirement.  Units 
using  JBC-P  experienced  situational  awareness  of  blue  (friendly)  forces  through  the  use  of  an 
improved  interface  and  higher  resolution  maps.  For  test  purposes,  vehicle-home  JBC-P  systems 
are  defined  as  “movers”  and  TOC  kits  are  “stationary.”  As  the  number  of  samples  for  each  case 
was  large  (15  thousand  to  2.7  million),  the  stated  success  rate  is  statistically  significant  and  a 
confidence  region  is  not  appropriate. 
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Table  3-1.  JBC-P  Blue  Force  Visibility  Rates 


Cases 

(JBC-P  to 
JBC-P) 

Requirement 
to  be  Seen 
within  xx 
Seconds 

Immediate 
(<5  km) 

Required  >  75% 

Extended 
(5-10  km) 
Required  >  65% 

Beyond 
(>10  km) 

No  User  Requirement 

IOT&E 

(NIE  13.2) 

Build  5.0 

MOT&E 

(NIE  14.2) 

Build  6.0 

IOT&E 

(NIE  13.2) 

Build  5.0 

MOT&E 

(NIE  14.2) 

Build  6.0 

IOT&E 

(NIE  13.2) 

Build  5.0 

MOT&E 

(NIE  14.2) 

Build  6.0 

Mover  to 
Mover 

8 

91.7% 

87.2% 

88.4% 

81.6% 

87.5% 

64.6% 

Mover  to 
Stationary 

8 

90.2% 

77.7% 

90.1% 

81.9% 

86.3% 

68.6% 

Stationary  to 
Mover 

1,200 

93.9% 

85.4% 

94.3% 

89.2% 

93.9% 

83.3% 

Stationary  to 
Stationary 

1,200 

91.3% 

90.3% 

97.7% 

94.7% 

92.3% 

95.1% 

Note:  80%  confidence  bounds  for  all  percentages  in  table  are  within  +/-  0.4%  of  the  point  estimate  due  to  the  large 
sample  sizes  of  instrumented  data  (1 5K  -  2.7M  samples). 


The  JBC-P  continued  to  provide  blue  force  situational  awareness  across  the  network  at 
completion  rates  above  the  user’s  requirements,  but  at  rates  lower  than  demonstrated  at  the  JBC- 
P  Software  Build  5.0  IOT&E.  The  lower  rates  seen  during  MOT&E  (compared  to  IOT&E)  may 
be  the  result  of  an  increased  number  of  unclassified  systems  sharing  situational  awareness 
messages.  The  exchange  of  messages  between  classified  and  unclassified  systems  requires 
transfer  between  JBC-P  and  JCR  Network  Operations  Centers  (NOCs),  which  delays  message 
completion.  Test  instrumentation  does  not  allow  discrimination  between  the  classified  and 
unclassified  messages. 

Commanders  and  Soldiers/Marines  noted  JBC-P  problems  with  “racing”  icons  moving  at 
high  speeds  across  the  area  of  operations  and  “ghost”  icons  displayed  in  a  location  that  did  not 
match  their  actual  position  location.  At  times,  JBC-P’s  display  of  situational  awareness  icons 
was  inaccurate  or  moving  at  high  rates  of  speed,  and  detracted  from  the  unit’s  ability  to 
accomplish  its  mission.  Moving  icons  included  stationary  TOCs,  some  moving  at  speeds  up  to 
200  kilometers  per  hour.  For  most  of  the  “ghost”  icons,  operators  could  physically  see  adjacent 
platforms  and  recognize  the  icon  on  the  map  was  in  the  wrong  place,  as  it  would  be  well  outside 
viewing  range  as  depicted.  Additional  “ghost”  icons  were  identified  when  communicating  with 
units  and  noting  a  discrepancy  in  their  location.  When  encountering  these  problems,  Soldiers 
and  Marines  lost  confidence  in  JBC-P  and  had  to  contact  the  unit  by  chat  or  radio 
communications  to  determine  its  actual  location. 

To  illustrate  racing  icons,  Table  3-2  shows  the  distribution  of  situational  awareness 
messages  by  sender  type  and  state  of  movement.  Each  situational  awareness  message  reports 
position  location  with  speed.  There  were  5,737  of  246,873  messages  (2.3  percent)  that  reported 
TOCs  moving  at  speeds  greater  than  0  kilometers  per  hour,  with  speeds  ranging  from  0  to  200 
kph.  This  is  not  possible  because  when  a  TOC  displaces,  the  JBC-P  system  is  turned  off  and 
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stowed  as  cargo  for  movement.  Figures  3-1  and  3-2  provide  a  breakdown  of  movement  speeds 
for  JBC-P  vehicles  and  stationary  TOCs.  While  tactical  vehicle  speeds  should  not  exceed  70 
KPH  under  normal  operations,  JBC-P  provided  over  3,200  situational  awareness  messages  that 
reported  vehicles  moving  at  speeds  ranging  from  greater  than  70  to  200  KPH  (Figure  3-1). 
While  JBC-P  TOC  kits  do  not  produce  situational  awareness  messages  on  the  move,  JBC-P 
provided  over  5,700  situational  awareness  messages  that  reported  TOCs  moving  at  speeds 
ranging  between  0  and  200  KPH  (Figure  3-2).  JBC-P  Software  Build  5.0  experienced  this 
deficiency  during  the  JBC-P  IOT&E.  During  the  subsequent  NIE  15.1,  JBC-P  continued  to 
experience  this  problem. 


Table  3-2.  State  of  Situational  Awareness  Senders  by  Movement  Type 


Types 

Number 

0  KPH 

>0  KPH 

Vehicles 

2,978,994 

(92.3%) 

2,534,577 

(85.1%) 

444,417 

(14.9%) 

TOCs 

246,873 

(7.7%) 

241,136 

(97.7%) 

5,737 

(2.3%) 

Total 

3,225,867 

2,775,713 

450,154 
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Figure  3-1.  Vehicle  Situational  Awareness  messages  with  speeds  greater  than  zero. 
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Figure  3-2.  TOC  Situational  Awareness  messages  with  speeds  greater  than  zero. 

JBC-P  displayed  joint  position  location  infonnation.  The  Marine  Corp  unit  displayed 
Army  platform  locations  and  vice  versa.  The  2-8  Marines  use  of  JBC-P  enabled  situational 
awareness  of  Army  units  within  their  area  of  operations  prior  to  receiving  the  information  from 
higher  headquarters. 

During  NIE  15.1,  JBC-P  displayed  situational  awareness  icons  that  were  lagging  by  30 
minutes  to  one  hour.  Soldiers  noted  this  problem  during  road  marches  and  unit  movements. 
During  the  last  three  days  of  NIE  15.1,  the  program  office  installed  a  software  patch  to  one 
maneuver  company  to  adjust  the  central  processing  unit  utilization.  This  effort  reduced  the  lag 
time  of  situational  awareness  icons  to  2-3  minutes,  but  introduced  an  additional  delay  of  images 
and  graphics.  Soldiers  did  not  have  confidence  in  the  situational  awareness  provided  by  JBC-P, 
and  confirmed  locations  by  other  communications  means  such  as  JBC-P  chat  and  combat  net 
radio. 

Command  and  Control  (C2)  Messaging 

Commanders  and  Soldiers/Marines  using  JBC-P  were  able  to  send  and  receive  C2 
messages  in  support  of  combat  operations.  Nonetheless,  during  MOT&E,  JBC-P  demonstrated 
message  completion  rates  below  the  user’s  requirement  for  Reports  and  Survivability  messages 
(comparable  to  the  IOT&E).  Table  3-3  and  Figure  3-4  show  the  demonstrated  message 
completion  rates  of  C2  messages  with  speed  of  service  compared  to  the  user’s  requirement  and 
demonstrated  performance  from  IOT&E.  JBC-P  did  not  meet  the  user’s  requirement  for  sending 
and  receiving  Survivability,  Reports,  and  Planning  C2  messages.  The  assessment  of  Fires  C2 
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message  data  is  not  conclusive  due  to  a  small  sample  size.  Although  JBC-P  did  not  meet  its 
requirement,  units  did  not  experience  reduced  mission  effectiveness  due  to  the  availability  of 
alternate  communications  means,  redundancy  of  JBC-P  systems  and  the  network’s  resending  of 
messages. 


Table  3-3.  JBC-P  Message  Completion  Rates  within  Speed  of  Service 


Observed 

Message 

Categories 

Message 
Completion  Rate 
(MCR)  w/in  Speed 
of  Service  (SOS) 
Requirement 

IOT&E 

MOT&E 

MCR  w/in 
SOS 

Unique  Sample 
Messages 

Overall  MCR 

MCR  w/in  SOS 

(80%  Confidence 
Bound) 

Survivability 

95%  <  1 5  seconds 

81.8% 

961 

83.3% 

81.9% 

(80.1% -83.4%) 

Mayday 

930 

82.9% 

81.9% 

MEDEVAC 

31 

96.8% 

93.6% 

Fires 

90%  <  15  seconds 

— 

7 

100% 

1 00% 

Reports 

90%  <  30  seconds 

86.0% 

8,698 

93.7% 

88.3% 

(87.8%  -  88.7%) 

Free  Text 

4,914 

93.8% 

87.4% 

Situation  Report 

2,136 

96.5% 

94.1% 

Overlay 

966 

88.6% 

82.4% 

Other 

682 

90.1% 

85.0% 

Planning 

90%  <  900 
seconds 

.... 

167 

88.0% 

88.0% 

(84.1% -91.1%) 

JBC-P  software  supports  four  types  of  C2  messages:  Survivability,  Fires,  Reports,  and 
Planning.  During  the  MOT&E,  commanders  and  Soldiers/Marines  used  Survivability,  Reports, 
and  Planning  messages,  with  Reports  messages  used  most  often.  As  shown  in  Table  3-3  above, 
the  most  common  Reports  message  was  the  Free  Text  message  (56  percent  of  messages) 
followed  by  Situation  Report  (25  percent  of  messages).  The  Survivability  messages  were 
predominately  Mayday  messages,  which  presented  a  significant  problem  during  the  MOT&E  due 
to  false  messages  (see  discussion  below).  Commanders  and  Soldiers/Marines  used  Planning 
messages  to  transmit  operations  and  fragmentary  orders.  Commanders  and  Soldiers/Marines 
preferred  to  use  chat  for  many  of  the  functions  intended  for  C2  messages.  Chat  is  the  primary 
tool  for  conducting  on-the-move  C2  within  the  brigade.  This  does  not  represent  a  reduction  in 
C2  effectiveness,  but  represents  Soldiers/Marines  using  JBC-P  in  an  innovative  manner  not 
envisioned  during  the  creation  of  the  user  requirement. 
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Figure  3-3.  JBC-P  Message  Completion  Rates  within  Speed  of  Service 
for  Various  Message  Types  and  Sub-Types 


JBC-P  has  a  major  deficiency  with  “phantom”  Mayday  messages.  Soldiers  and  Marines 
send  a  Mayday  message  when  the  tactical  situation  demands  immediate  assistance  for  a  unit 
under  duress.  All  of  the  930  Mayday  messages  seen  during  MOT&E  were  false  messages 
generated  from  multiple  systems  (both  moving  and  stationary)  without  the  operator’s  knowledge 
or  initiation.  Soldiers  in  focus  groups  and  interviews  stated  that  they  did  not  use  this  function 
(i.e.  initiate  Maydays)  during  missions,  meaning  that  all  of  the  Mayday  messages  observed 
during  the  MOT&E  were  phantom  messages.  Soldiers  and  Marines  receiving  phantom  Mayday 
messages  lost  confidence  in  JBC-P.  Since  they  did  not  know  if  the  Mayday  messages  were  real, 
Soldiers/Marines  had  to  contact  the  originator  of  each  message  to  determine  authenticity. 
Phantom  Mayday  messages  increased  the  operator’s  workload  to  verify  status,  and  cluttered  the 
display  with  false  icons  (up  to  50  at  a  time),  which  obstructed  the  view  of  valid  information  and 
required  user  effort  to  clear  the  screen.  This  is  a  new  problem  in  JBC-P  Software  Build  6.0,  as 
no  Mayday  messages  were  transmitted  or  observed  during  the  IOT&E. 

During  NIE  15.1,  Soldiers  continued  to  experience  phantom  Mayday  messages  despite 
two  software  patches  to  fix  the  problem.  The  program  office  installed  the  first  software  patch  to 
reduce  the  frequency  of  the  self-generated  Mayday  messages  and  the  second  to  require  a  two- 
step  process  for  the  Mayday  “hot  button”  (to  prevent  the  operator  hitting  the  button  in  error). 
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Soldiers  reported  they  did  not  send  intentional  Mayday  messages  during  NIE  15.1,  yet  the 
problem  of  phantom  Mayday  messages  continued.  The  Army  should  fix  this  deficiency  and 
verify  the  correction  in  an  operational  test  prior  to  fielding  JBC-P  Software  Build  6.0. 

Shared  Survivability/Entity  Data  Messages 

JBC-P  Software  Build  6.0  demonstrated  poor  message  completion  rates  within  speeds  of 
service,  well  below  the  user  requirement,  for  Shared  Survivability  data  of  battlefield  hazards.  A 
subset  of  C2  messages  (e.g.  Alert,  Warning,  Bridge,  Obstacle,  Enemy  Location,  Hazard  Area, 
and  Supply  Location)  generate  Shared  Survivability  data,  tenned  Entity  Data  Messages  (EDMs), 
and  broadcast  these  to  other  platforms  within  a  geographic  radius  known  as  the  danger  zone. 
Danger  zones  vary  in  radial  distance  from  5  to  40  kilometers.  This  is  based  upon  the  threat 
contained  within  the  survivability  message,  e.g.  artillery  has  a  40-kilometer  danger  zone  while  an 
improvised  explosive  device  (IED)  has  a  10-kilometer  danger  zone.  The  user  requirement 
defines  the  transfer  of  Shared  Survivability  data  to  75  percent  of  the  systems  within  the  danger 
zone  must  occur  in  less  than  15  seconds. 

During  the  JBC-P  IOT&E,  Software  Build  5.0  met  the  Shared  Survivability/EDM  data 
requirement.  JBC-P  Build  6.0  modified  the  dissemination  of  Shared  Survivability/EDM  data  to 
include  both  NOC  dissemination  (as  with  Build  5.0)  and  the  transfer  of  messages  across  the 
JBC-Ps’  Network  Services  Gateway  (NSG)  using  both  terrestrial  and  satellite  transmissions. 

The  Army  changed  the  dissemination  of  messages  to  gain  access  to  a  wider  group  of  recipients  in 
a  shorter  time  period. 

Table  3-4  displays  the  distribution  of  message  completion  rates  for  Shared 
Survivability/EDM  data  sent  during  the  MOT&E  assessed  by  visibility  within  the  danger  zone 
and  speed  of  service  with  associated  transmission  path. 
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Table  3-4.  Distribution  of  Survivability  EDM  Visibility  within  Danger  Zones 


EDM  Transmission 
Path 

Total  EDM  w/in  DZs 

(MCR  &  SOS  data) 

Visible  w/in  DZ  -  (Requirement  = 
75%  within  15  seconds) 

IOT&E 
(NIE  13.2) 
Build  5.0* 

MOT&E 
(NIE  14.2) 
Build  6.0 

IOT&E 
(NIE  13.2) 
Build  5.0 

MOT&E 

(NIE  14.2)  Build  6.0 

MCR 

MCR  w/in  15 
seconds 

Original  JBC-P 
Transmission 

1,018 

482 

84% 

42.7% 

40.9% 

JBC-P  NSG 
Re-Dissemination 

.... 

3,844 

— 

84.1% 

71.5% 

Sub-Total 

1,018 

4,326 

84% 

79.5% 

68.1% 

NOC 

Re-Dissemination 

84,652  * 

6,540 

99% 

74.5% 

46.1% 

Total 

85,670 

10,866 

99% 

76.5% 

54.9% 

MCR  -  Message  Completion  Rate;  SOS  -  Speed  of  Service;  EDM  -  Entity  Data  Message 
*  Message  count  methodology  in  IOT&E  (NIE  13.2)  was  different  from  MOT&E  (NIE  14.2). 


JBC-P  Software  Build  6.0  demonstrated  poor  performance  of  the  Shared 
Survivability/EDM  capability,  providing  a  40.9  percent  completion  rate  from  sender  to  receiver 
within  required  time  and  danger  zone  distance  compared  to  a  user  requirement  of  75  percent. 

The  NSG  re-disseminations  provided  a  better  message  completion  rate  within  an  additional  15 
seconds,  demonstrating  a  rate  of  71.5  percent,  but  even  with  an  additional  15  seconds,  this  rate 
still  does  not  meet  the  basic  user  requirement  of  75  percent  of  EDMs  being  displayed  within  15 
seconds.  The  combined  rate  for  the  original  transmission  and  the  NSG  re-dissemination  was 
68.1  percent.  In  order  to  meet  a  75  percent  completion  rate,  JBC-P  required  12  to  15  minutes  to 
deliver  Shared  Survivability/EDM  data  within  its  prescribed  danger  zone  (well  beyond  the  15- 
second  requirement). 

The  user  intends  that  Shared  Survivability/EDM  data  are  shared  quickly  and  efficiently 
within  the  prescribed  danger  zone.  Receiving  an  EDM  within  12  to  15  minutes  might  be 
acceptable  for  a  damaged  bridge  across  a  40-kilometer  danger  zone,  but  would  not  be  acceptable 
for  an  IED  within  5  kilometers  in  a  danger  zone.  The  Shared  Survivability/EDM  data  problem 
should  be  fixed  prior  to  fielding. 

The  types  of  Survivability/EDMs  are  displayed  in  Figure  3-5.  The  data  show  that  leaders 
and  Soldiers/Marines  generated  77  percent  of  their  EDMs  with  Maneuver  Platforms/Ground 
Vehicle/Mortars  Survivability  messages. 
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Figure  3-4.  Types  of  Survivability/Entity  Data  Messages  Used  During  MOT&E 

JBC-P’s  management  of  EDMs  is  not  effective.  The  number  of  EDMs  displayed  on  the 
JBC-P  confused  Soldiers.  Danger  zone  distances  are  based  on  the  effective  range  of  the 
indicated  threats  and  over  time  resulted  in  so  many  warnings  that  Soldiers  “tuned  them  out.” 
Another  problem  with  the  icons  and  their  alerts  was  the  duration  of  the  icons.  The  common  Spot 
Report  EDM  (used  to  send  intelligence  or  event  status)  had  a  default  time  frame  to  disappear 
after  12  hours.  All  other  EDM  icons  (such  as  IED,  generated  from  an  IED  or  Bridge  Report) 
remained  current  until  deleted.  Without  techniques  and  procedures  to  maintain  the  JBC-P  EDM 
information,  the  displays  became  cluttered  with  icons,  which  Soldiers  ignored  as  not  current. 

The  Army  and  Marines  should  improve  their  procedures  to  maintain  the  threat  situational 
awareness  provided  by  Shared  Survivability  messages  and  EDMs.  A  unit  digital  standard 
operating  procedure  for  management  of  enemy  situational  awareness  information  combined  with 
appropriate  training  would  enhance  the  effectiveness  of  JBC-P’s  red  (enemy)  situational 
awareness. 

Force  Effectiveness 

JBC-P  demonstrated  limited  utility  in  contributing  to  the  unit’s  force  effectiveness  during 
missions  of  the  JBC-P  MOT&E.  Following  the  completion  of  the  MOT&E,  DOT&E  and  the 
Army  Test  and  Evaluation  Command  employed  a  panel  of  military  subject  matter  experts  to 
assess  JBC-P’s  force  effectiveness  during  nine  MOT&E  missions.  As  shown  in  Figures  3-6  and 
3-7,  the  DOT&E  and  panel  assessed  each  mission  against  the  following  force  effectiveness 
components. 

•  Mission  Success.  Mission  success  is  an  assessment  of  the  unit’s  ability  to  complete 
their  mission  while  preserving  combat  power  for  future  operations.  Mission  success 
was  scored  on  a  5-point  scale  ranging  from  1  as  “failure”  to  5  as  “fully  successful.” 

•  Mission  Utility.  Mission  Utility  is  an  assessment  of  JBC-P’s  contributions  to  the  unit 
accomplishing  its  task.  Mission  utility  was  scored  on  a  4-point  scale  ranging  from  1 
as  “not  used”  to  4  as  “effective  utility.” 
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Scores  ranged  from  1  (Failure)  to  5  (Fully  Successful).  The  panel  scored  each  of  the  9  missions. 
Figure  3-5.  Blue  Ribbon  Panel  Voting  -  Mission  Success 


Effective  Utility 


Not  Used 

0  2  4  6  8  10 

Number  of  Missions 

Scores  ranged  from  1  (Not  Used)  to  4  (Effective  Utility).  The  panel  scored  each  of  the  9  missions. 
Figure  3-6.  Blue  Ribbon  Panel  Voting  -  Mission  Success 

Units  using  JBC-P  accomplished  their  mission  (three  Marine  missions  and  six  Army 
missions)  when  employing  JBC-P  during  MOT&E  missions. 

•  Mission  Success.  Soldiers,  Marines,  and  leaders  accomplished  their  nine  missions, 
which  were  assessed  by  the  Blue  Ribbon  Panel  with  no  more  than  10  percent 
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casualties  or  loss  of  equipment.  Mission  success  ranked  as  a  4.0  on  a  5-point  scale  in 
9  of  9  missions. 

•  Mission  Utility.  Primarily  using  chat,  which  is  a  legacy  capability,  JBC-P  provided 
situational  awareness  to  Soldiers  and  Marines  and  improved  the  unit’s  ability  to 
accomplish  its  mission  with  limited  utility  in  8  of  9  missions  (89  percent).  JBC-P 
provided  no  utility  to  the  unit’s  mission  in  1  of  9  missions  (11  percent).  On  average, 
JBC-P  mission  utility  ranked  as  a  2.89  on  a  4-point  scale. 

The  following  summary  observations  highlight  JBC-P  contribution  to  mission 
accomplishment: 

•  JBC-P  provided  timely  situational  awareness  information  (primarily  through  chat)  to 
support  combat  operations. 

•  Soldiers,  Marines,  and  leaders  across  the  brigade  and  regiment  used  chat  to  enhance 
force  effectiveness.  Military  experts  on  the  force  effectiveness  panel  assessed  that  the 
use  of  JBC-P  improved  situational  awareness  and  reduced  occurrences  of  fratricide. 

•  JBC-P  chat  served  as  the  primary  command  and  control  backup  to  combat  net  radio 
voice  communications  across  all  brigade  and  regiment  echelons. 

•  Leaders  used  JBC-P  for  planning  routes  and  tracking  unit  movement,  especially  in 
conditions  of  low  visibility. 

•  JBC-P  allowed  the  marking  of  IEDs  and  other  obstacles,  which  allowed  follow-on 
forces  to  avoid  these  hazards. 

•  Management  of  JBC-P’s  enemy  force  situational  awareness,  to  include  removal  of 
stale  red  icons  and  more  frequent  updates  of  enemy  forces,  needs  improvement 
through  development  of  tactics,  techniques,  and  procedures;  training;  and  system 
improvement. 

Unit  Task  Reorganization 

The  test  unit  successfully  conducted  Unit  Task  Reorganizations  (UTRs)  with  JBC-P. 

UTR  with  the  JBC-P  is  exercised  by  the  brigade  commander  or  S-3,  and  executed  by  the  S-6. 
When  executed,  the  UTR  function  reconfigures  the  JBC-P  network  to  support  information 
transfer  to  realigned  units,  which  enabled  the  brigade  to  be  reorganized  for  combat.  Operators 
reported  that  the  UTR  task  was  simple  and  intuitive. 

In  the  MOT&E,  there  were  14  separate  UTR  actions  that  occurred  during  the  record  test. 
Of  the  14  distinct  UTRs,  the  unit  changes  or  task  reorganizations  occurred  at  the  platoon, 
company,  battalion,  and  regiment  echelons.  These  included  intra-  and  inter-Service  (i.e.,  Army 
to  Army  and  Army  to  Marine  Corps  and  vice  versa)  UTRs.  The  key  UTRs  were: 

•  2-8  Marines  into  (and  back  out  of)  the  2-1  AD 

•  F  Company,  2-8  Marines  into  (and  back  out  of)  1-6  INF 
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•  C  Troop,  1-1  CAV  into  (and  back  out  of)  4-17  INF 

•  D  Company,  1-6  INF  and  A  Troop,  1-1  CAB  into  (and  back  out  of)  2-8  Marines 

The  unit  was  successful  with  all  UTRs  executed  using  JBC-R  As  part  of  the  UTR 
process,  Self-Descriptive  Situational  Awareness  (SDSA)  information  providing  position  location 
information  and  organizational  structure  is  posted  to  the  Data  Dissemination  Service  for  use  by 
other  users.  Upon  completing  the  UTR,  the  involved  units  are  supposed  to  have  visibility  of 
their  unit  changes.  During  the  MOT&E,  the  “as  of  times”  within  the  SDSA  were  not  accurate 
and  were  not  consistent  for  about  10  percent  of  the  UTR  records,  which  provided  misinformation 
to  units  and  incorrect  updates  to  the  brigade’s  Data  Dissemination  Service.  This  error  did  not 
affect  the  UTR  or  reduce  the  JBC-P  functionality,  and  had  negligible  impact  on  the  unit. 

Hybrid  Capability 

The  JBC-P  Software  Build  6.0  system  provided  a  successful  hybrid  capability  via  NSG 
software  loaded  on  each  system.  The  capability  allows  the  system  to  simultaneously  send  C2, 
Situational  Awareness  Visibility,  Survivability,  and  Chat  messages  via  satellite  and  terrestrial 
radios.  In  the  case  of  a  Blue  Force  Tracker  2  (BFT2)  satellite  failure,  the  platfonn  will  become  a 
client  of  another  local  platfonn,  which  is  configured  as  a  gateway  on  the  terrestrial  network. 
JBC-P  demonstrated  this  capability  with  40  Army  and  Marine  hybrid  systems  sending  out 
686,157  messages  simultaneously  via  satellite  BFT2  and  the  terrestrial  network.  Note  however, 
that  although  dual-transmission  occurred,  message  completion  rates  were  often  below 
requirements,  and  information  transmitted  was  inaccurate. 

Digital  Maps  and  COMSEC  Failures 

The  digital  maps  used  by  JBC-P  Software  Build  6.0  during  the  NIE  14.2  MOT&E  and 
NIE  15.1  are  not  current.  Soldiers  zooming  in  or  out  of  maps  experienced  slow  processing,  and 
at  times  the  software  locked  up,  which  required  up  to  10  minutes  to  reboot  the  system.  Soldiers 
reported  that  when  they  zoom  in  on  a  map,  the  display  is  a  checkerboard  mixture  of  imagery  and 
maps.  Map  grid  lines  are  not  accurate,  and  at  times  were  displayed  offset  between  800  to  1,500 
meters.  The  program  office  reported  that  auto  grid  lines  work  fine,  but  the  user  selectable  grid 
lines  should  not  be  used.  The  Army  needs  to  fix  JBC-P  map  software  problems  and  not  rely 
upon  training  (i.e.,  only  use  auto  grid  lines)  as  a  solution. 

The  JBC-P  system  communications  security  (COMSEC)  device,  KGV-72,  continued  to 
drop  COMSEC  encryption  key  fills  during  NIE  15.1.  When  this  happens,  the  Soldier’s  JBC-P  is 
not  operational  until  he  receives  assistance  from  the  unit’s  communications  maintenance 
specialist  or  contractor  field  service  representatives.  The  delay  awaiting  qualified  personnel  to 
rekey  the  KGV-72  detracted  from  unit  mission  accomplishment.  Training  provided  to  Soldiers 
on  the  KGV-72  was  not  effective. 

JBC-P  Log 

As  an  integral  component  of  JBC-P  Software  Build  6.0,  JBC-P  Log  did  not  support  the 
Army  brigade’s  logistics  mission.  The  Army  intends  JBC-P  Log  to  interrogate  RFID  tags, 
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transfer  the  information  into  Army  logistics  systems,  and  allow  Soldiers  to  track  cargoes  in  a 
dynamic  manner.  Per  operator  consensus,  Soldiers  reported  a  30  -  40  percent  success  rate  in 
interrogating  RFID  tags  for  data  entry  into  the  logistics  tracking  system.  Once  interrogated  and 
entered  into  the  system,  JBC-P  Log  allowed  operators  to  input  duplicate  tags  without  removing 
the  tag  from  its  cargo  mission.  This  deficiency  caused  duplicate  cargoes  in  brigade  transport 
vehicles,  and  the  brigade  lost  visibility  of  its  cargo  assets  because  of  JBC-P  Log.  Operators  did 
not  have  the  training  or  experience  to  correct  the  problem.  Brigade  field  service  representatives 
attempted  to  fix  this  problem  by  reimaging  computer  hard  drives  from  42  JBC-P  Log  systems 
during  the  weekend  prior  to  record  test.  At  the  start  of  record  test,  39  of  42  JBC-P  Log  systems 
were  available  to  conduct  missions.  JBC-P  Log  was  not  returned  to  full  mission  capability  until 
the  second  day  of  record  test.  Even  with  refresher  training  and  reimaged  hard  drives,  the  unit 
continued  to  experience  the  JBC-P  Log  problems  discussed  above.  The  JBC-P  Log  system  did 
not  support  the  unit’s  logistics  mission  and  the  Army  does  not  have  effective  tactics,  techniques, 
or  procedures  for  the  employment  of  JBC-P  Log. 

JBC-P  Log  supplies  information  to  the  larger  Army  logistics  system  to  provide  updates  to 
the  In-Transit  Visibility  (ITV)  servers.  Figure  3-7  shows  the  portion  of  the  operational 
environment  that  was  instrumented  for  the  JBC-P  Log  systems  during  NIE  14.2.  Once  the 
Soldier  was  able  to  interrogate  the  RFID  tag,  JBC-P  was  able  to  transfer  the  data  to  the  JBC-P 
NOC  for  transfer  through  the  Movements  Tracking  System-Enhanced  Software  to  the  ITV 
servers.  The  10  instrumented  JBC-P  Log  platforms  and  2  control  stations  sent  a  total  of  1,388 
RFID  Tag  Reports,  Queries,  and  Searches  across  94  unique  tags  to  the  JBC-P  NOC.  The  JBC-P 
NOC  received  98.1  percent  of  these  messages.  JBC-P  Log  maintains  a  satisfactory  link  to  the 
NOC.  Future  testing  should  assess  transfer  of  information  to  the  destination  ITV  servers. 


Figure  3-7.  JBC-P  Log  Operational  Environment 


During  NIE  15.1,  JBC-P  Log  operators  experienced  problems  communicating  with  the 
command  elements  of  the  brigade.  The  JBC-P  Log  is  an  unclassified  system  designed  to  support 
logistics  operations,  while  JBC-P  supports  mission  command  in  a  classified  network.  JBC-P 
Log  does  not  allow  sustainment  units  (logistics  and  personnel)  to  participate  in  JBC-P  chat 
sessions  to  discuss  ongoing  classified  brigade  operations.  There  are  not  enough  JBC-P  classified 
systems  within  sustainment  units  to  satisfy  the  units’  need  for  coordination  with  the  brigade’s 
combat  formations. 
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Section  Four 

Suitability 

The  Joint  Battle  Command  -  Platform  (JBC-P)  is  not  operationally  suitable.  JBC-P  is  not 
reliable  for  most  versions  of  hardware  hosting  JBC-P  Software  Build  6.0.  During  the  Multi- 
Service  Operational  Test  and  Evaluation  (MOT&E),  which  occurred  during  Network  Integration 
Evaluation  (NIE)  14.2,  DOT&E  evaluated  the  reliability,  availability,  and  maintainability  of 
major  JBC-P  system  configurations  employed  by  Army  and  Marine  Corps  units: 

•  Joint  Version  5  (JV5) 

-  Block  I  Computer  System 

-  Block  II  Computer  System 

•  Military  Family  of  Computing  Systems  (MFoCS) 

-  MFoCS-Basic  (MFoCS-B) 

-  MFoCS-Intermediate(MFOCS-I) 

•  Tactical  Operations  Center  (TOC)  Kit 

-  Dell  XFR  TOC 

-  MFoCS-B  TOC 

•  JBC-P  Logistics  (JPC-P  Log) 

-  Military  Rugged  Tablet  -  Plus  (MRT+) 

-  MRT+  Control  Station  (MRT+  CS,  TOC) 

JBC-P  experienced  inconsistent  reliability  across  the  spectrum  of  the  major  JBC-P 
system  configurations.  Some  configurations  performed  well,  but  most  did  not  meet  the  Mean 
Time  Between  Essential  Function  Failure  (MTBEFF)  requirement  of  290  hours.  Fifty-eight 
percent  of  JBC-P  Essential  Function  Failures  were  due  to  software.  With  the  exception  of  the 
JBC-P  Log  MRT+,  all  mobile  JBC-P  systems  met  the  user’s  80  percent  operational  availability 
requirement.  While  the  Marine  Corps  XFR  TOC  system  met  the  requirement,  the  Army’s  use  of 
the  XFR  in  a  TOC  did  not  meet  the  operational  availability  requirement. 

JBC-P  met  the  30-minute  Mean  Time  To  Repair  (MTTR)  maintainability  requirement  for 
all  variants  of  the  system.  Soldiers  and  Marines  were  able  to  maintain  the  system  because  most 
failures  were  software-related  and  the  crew  could  correct  them  by  rebooting  the  system  without 
maintenance  support.  The  reboot  process  requires  three  steps:  power  down,  power  up,  and  log 
in.  The  average  time  for  a  JBC-P  reboot,  to  include  system  spontaneous  rebooting  during 
MOT&E,  was  eight  minutes. 

JBC-P  training  prepared  Soldiers  and  Marines  to  install  and  operate  their  mobile  and 
TOC  systems.  The  Army  should  consider  improving  the  training  to: 

•  Provide  sufficient  time  for  unit  collective  training. 
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•  Increase  hands-on  instruction. 

•  Increase  troubleshooting  instruction  for  maintainers. 

•  Provide  leaders  with  infonnation  tailored  to  their  command  or  staff  position. 

•  Provide  technical  manuals  to  Soldiers  and  Marines. 

The  JBC-P  Log  training  provided  to  Soldiers  by  the  Army  was  not  effective.  Even  with 
retraining  at  the  beginning  of  record  test,  training  did  not  prepare  them  to  operate  or  maintain 
JBC-P  Log. 

Reliability 

JBC-P  is  not  reliable.  Table  4-1  shows  the  MTBEFF  experienced  during  MOT&E  for  the 
six  vehicle -mounted  configurations  and  two  TOC  Kit  configurations.  On  June  4,  2013,  the 
Army  approved  lowering  the  JBC-P  MTBEFF  requirement  from  470  hours  to  290  hours.  The 
Marine  Corps  concurred  with  this  lowered  threshold  requirement.  The  Operational  Availability 
requirement  remained  unchanged  at  0.90. 


Table  4-1.  Demonstrated  MTBEFF  in  the  MOT&E 


Operating 
Hours 
(#  of 

Systems) 

Essential 

Function 

Failures 

MTBEFF 

Point 

Estimate 

(hours) 

MTBEFF  80% 
Confidence  Bounds 
(hours) 

MTBEFF 

Requirement 

(hours) 

2-Sided 

Lower 

Army  Systems 

JV5  Block  1 

1,405  (10) 

1 

1,405 

361-1,336 

469 

290 

JV5  Block  2 

1,441  (12) 

0 

... 

... 

895 

290 

MFoCS-B 

2,865  (20) 

0 

... 

... 

1780 

290 

MFoCS-l 

2,695  (20) 

12 

225 

152-344 

170 

290 

MFoCS-B 

TOC 

506  (3) 

3 

169 

76-459 

92 

None 

XFR  TOC 

380  (2) 

1 

380 

98-3,607 

127 

None 

MRT+ 

449  (10) 

5 

90 

48-185 

57 

None 

MRT-CS 

224  (2) 

1 

224 

58-2,126 

75 

None 

Marine  Corps  Systems 

JV5  Block  1 

954  (7) 

3 

318 

143-866 

173 

290 

XFR  TOC 

156  (1) 

0 

... 

Not  Demonstrated 

None 

—  =  Undefined.  Cannot  divide  by  0 

Since  all  vehicle-mounted  and  TOC  JBC-P  variants  must  support  Soldiers/Marines  within 
the  same  mission,  all  system  variants  are  assessed  against  the  user’s  requirement  of  290  hours 
MTBEFF.  Both  of  the  JV5  configurations  (Block  1  and  Block  2)  met  or  exceeded  the 
requirement.  The  Army’s  data  for  the  MFoCS-B  mounted  configuration  yielded  a  very  high 
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reliability  estimate  (80  percent  lower  confidence  bound  =  1,780  hours),  but  the  MFoCS-B 
performance  was  not  consistent  with  the  same  hardware  in  the  TOC  configuration  that 
demonstrated  an  MTBEFF  of  92  hours  (80  percent  lower  confidence  bound).  The  MFoCS-I 
mounted  configuration  experienced  poor  reliability,  with  an  80  percent  lower  confidence  bound 
of  170  hours.  The  remaining  five  JBC-P  configurations  did  not  meet  the  user’s  reliability 
requirement. 


Table  4-2.  Demonstrated  Mission  Reliability  and  Platoon  Reliability 


Operating 

Hours 

(#  of  Systems) 

Mission 

Reliability 

Point  Estimate 

Mission  Reliability 
80%  Lower 
Confidence  Bound 

Probability  of 
Platoon  (3/4) 
Completing  a 
Mission 

Army  Systems 

JV5  Block  1 

1,405  (10) 

0.99 

0.86 

1.00 

JV5  Block  2 

1,441  (12) 

— 

0.92 

1.00 

MFoCS-B 

2,865  (20) 

— 

0.96 

0.96 

MFoCS-I 

2,695  (20) 

0.81 

0.74 

0.99 

MFoCS-B  TOC 

506  (3) 

0.65 

0.46 

N/A 

XFR  TOC 

380  (2) 

0.83 

0.57 

N/A 

MRT+ 

449  (10) 

0.45 

0.28 

N/A 

MRT-CS 

224  (2) 

0.73 

0.38 

N/A 

Marine  Corps  Systems 

JV5  Block  1 

954  (7) 

0.80 

0.66 

0.95 

XFR  TOC 

156  (1) 

— 

— 

N/A 

—  =  Undefined.  Cannot  divide  by  0 

The  majority  of  JBC-P  variants  did  not  achieve  (with  confidence)  the  required  Mission 
Reliability  of  80  percent  probability  of  completing  a  72-hour  mission  without  an  Essential 
Function  Failure  at  the  80  percent  lower  confidence  bound  (Table  4-2).  The  table  presents  both 
the  mission  reliability  of  a  single  system  and  the  reliability  of  three  out  of  four  vehicles  in  a 
platoon  completing  a  mission,  as  described  in  the  user’s  requirement.  The  MFoCS-B  (mounted) 
Mission  Reliability  demonstrated  reliability  well  above  the  MFoCS-B  in  the  TOCs  and  the 
MFoCS-I  in  mounted  configuration.  These  results  present  inconsistent  and  statistically  different 
results  for  the  MFoCS  hardware  configurations.  The  Army  should  conduct  further  investigation 
into  the  reduced  mission  reliability  of  the  MFoCS-B  operated  within  TOCs  compared  to  the 
MFoCS-B  operated  within  vehicles.  The  Marine  Corps  XFR  TOC  system  did  not  accumulate 
sufficient  operating  hours  to  produce  a  statistically  valid  estimate.  Because  the  TOCs  (MFoCS- 
B  TOC  and  XFR  TOC)  and  the  JBC-P  Log  (MRT+  and  MRT-CS)  systems  do  not  operate  in  a 
combat  platoon  configuration,  the  user’s  three  out  of  four  vehicles  mission  reliability  standard 
does  not  apply. 
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The  majority  of  JBC-P  failures  in  MOT&E  were  due  to  software.  The  following 
descriptions  provide  failure  categories  and  frequency  of  repeated  failures  during  the  JBC-P 
Software  Build  6.0  MOT&E.  Table  4-3  provides  a  further  breakdown  of  these  major  failure 
modes. 

•  System  Stall  (11  Failures).  JBC-P  stopped  responding  to  operator  input.  The 
system  would  return  to  operator  control  or  require  a  system  reboot.  The  system 
exhibited  symptoms  of  the  software  and  hardware  being  overtasked. 

•  Cryptographic  Recognition  (9  Failures).  The  JBC-P  lost  use  of  its  component 
Programmable  In-Line  Encryption  Device,  KGV-72.  When  loss  of  the  associated 
cryptographic  key  occurred,  unit  maintainers  had  to  zero  (erase)  the  KGV-72  key, 
reload  the  current  key,  and  reboot  the  JBC-P  system.  Since  the  operator  did  not  have 
the  key,  the  Unit  Maintainer  (Military  Occupational  Specialty  25U,  Signal  Support 
Specialist)  perfonned  this  action. 

•  Defense  Advanced  Global  Positioning  System  (GPS)  Receiver  (DAGR)  Problems 
(5  Failures).  JBC-P  lost  contact  with  the  GPS  information  provided  by  its 
component  DAGR. 
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Table  4-3.  Breakdown  of  Repeated  Failure  Modes  during  the  JBC-P  MOT&E 


General  Failure 
Mode  Description 

Number  of 
Failures 

Failure  new 
in  MOT&E? 

Comments 

System  Stall 

Spontaneous 

Reboot 

7 

No 

A  symptom  of  multiple  failures  that  could  not  be  isolated  from  test 
data.  Issue  sometimes  caused  by  the  system  self-rebooting  when 
internal  diagnostics  indicated  poor  system  health.  The  average 
reboot  time  is  8  minutes.  The  system  returned  with  the  log-on 
screen;  however,  any  unsaved  data  or  products  are  lost. 

Frozen  Display 

1 

No 

Display  does  not  respond  to  operator  inputs.  Operator  must 
reboot  system  to  recover. 

Spontaneous 

Shutdown 

1 

No 

JBC-P  spontaneously  turns  itself  off.  Crew  must  restart  system. 

All  open  and  unsaved  files  or  products  are  lost. 

Hard  Disk  Corrupt 

1 

No 

Replace  hard  disk. 

Cryptographic  Recognition 

Amber-Green 

2 

No 

When  KGV-72  status  LED  shows  amber  green,  JBC-P  has  lost 
synchronization  with  its  component  KGV-72.  The  operator  had  to 
zero  the  KGV-72  crypto  keys,  reload  crypto  keys,  and  reboot  the 
system. 

KGV-72  Red 

2 

No 

When  KGV-72  status  LED  shows  red,  cryptologic  functions  are 
suspended.  This  may  be  caused  by  any  number  of  internal  or 
external  events  that  the  cryptologic  device  interprets  as  a  hazard 
to  secure  data.  This  results  in  loss  of  all  communications.  The 
crew  could,  in  most  cases,  recover  with  a  reboot  of  the  system. 

KGV-72  Amber- 
Green 

2 

No 

Synchronization  between  JBC-P  hardware  and  KGV-72  is  lost. 

The  operator  had  to  zero  the  KGV-72  crypto  keys,  reload  crypto 
keys,  and  reboot  the  system. 

KGV-72  Down 

2 

No 

A  catch-all  for  failures  that  render  the  KGV-72  inoperable  but  are 
not  represented  above.  JBC-P  provides  no  user  support  if  the 
KGV-72  is  down. 

KGV-72  Flashing 
Green 

1 

No 

When  the  KGV-72  status  LED  shows  flashing  green,  this  indicates 
a  specific  KGV-72  failure  mode  that  requires  a  crypto  key  refill. 

Defense  Advanced  GPS  Receiver  (DAGR)  Problems 

GPS  Down 

4 

No 

DAGR  lost  GPS  connection.  Typically  resolved  with  a  DAGR 
reboot.  JBC-P  cannot  provide  user  location  until  this  problem  is 
resolved. 

GPS  Cable  Failure 

1 

No 

Replace  cable 

MRT 

RFID  Inoperable 

1 

Yes 

Reboot  System 

Tablet  Failure 

1 

Yes 

Replace  Tablet 

Messaging  Issues 

Message  Failure 

5 

No 

Reboot  System 

Overlay  Failure 

1 

No 

Self-correcting 

Graphics  Issue 

1 

Yes 

System  freezes  when  zooming  between  different  scale  maps. 
Rebooting  system  resolves  the  problem. 

Attachment  Failure 

1 

No 

Unknown  Failure  Mode 
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A  review  of  the  brigade  Trouble  Ticket  Log  (Table  4-4)  revealed  the  following  system 
failures  and  the  number  of  failures  that  required  Field  Service  Representative  (FSR)  Support. 
Although  the  emphasis  for  the  MOT&E  is  Record  Test,  the  table  also  provides  the  quantity  of 
trouble  tickets  reported  within  the  brigade  during  the  Pilot  Test. 


Table  4-4.  NIE  14.2  Trouble  Tickets  Summary 


Test 

Phase 

Types  of 
Repair 

2-1 

Brigade 

2-8 

Marines 

4-17 

Infantry 

1-1 

Cavalry 

47  Brigade 
Support 
Battalion 

Total 

FSR 

Support 

Required 

Pilot 

Software 

2 

3 

2 

7 

5 

Hardware 

4 

2 

10 

1 

17 

17 

Record 

Software 

3 

1 

1 

5 

10 

5 

Hardware 

1 

2 

4 

10 

13 

30 

15 

Key  Deficiencies  requiring  FSR  support: 

KGV-72  -  Rekeying  ,  Replaced 
Reconfigure  JBC-P  Hard  drives 
Cables  -  repair/replace 

Transceiver  -  replace/change  to  correct  data  group  or  network 
TIGR-  connectivity  with  JBC-P  and  operations 


Figure  4-1  shows  the  distribution  of  the  failures  by  category.  As  assessed  by  the  JBC-P, 
DOT&E,  and  MOT&E  Reliability  Availability  Maintainability  Scoring  Conference,  58  percent 
of  JBC-P  failures  were  due  to  software  and  23  percent  of  failures  were  due  to  hardware. 
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Availability 

Table  4-5  shows  the  Operational  Availability  (Ao)  derived  from  the  recorded  operating 
hours  and  associated  downtime  hours  during  the  MOT&E.  All  mobile  platforms  met  the  80 
percent  operational  availability  requirement  except  the  JBC-P  Log  MRT+.  The  Army’s  use  of 
the  XFR  in  a  TOC  (0.684)  did  not  meet  the  80  percent  operational  availability  requirement. 
These  results  are  not  consistent  with  the  Marine  Corps’  use  of  the  XFR  in  their  TOC,  which 
exceeded  (1.00)  the  requirement. 


Table  4-5.  Operational  Availability  (Ao)  Estimates  for  Hardware  Configurations 


A0  from  Record  Test  (Requirement  0.80) 

Configuration 

Operating  Hours 

Down  Time 
(hours) 

Aq 

Army  Systems 

JV5  Block  1  (Mobile) 

1,405.0 

0.4 

1.000 

JV5  Block  2  (Mobile) 

1,441.2 

0.0 

1.000 

MFoCS-B  (Mobile) 

2,864.9 

287.2 

0.909 

MFoCS-l  (Mobile) 

2,694.9 

463.9 

0.853 

MFoCS-B  (TOC) 

505.9 

4.8 

0.991 

XFR  (TOC) 

380.3 

176.0 

0.684 

MRT+  (Mobile) 

448.7 

358.8 

0.556 

MRT+  CS  (TOC) 

224.0 

41.0 

0.845 

Marine  Corps  Systems 

JV5  Block  1  (Mobile) 

953.5 

100.3 

0.905 

XFR  (TOC) 

156.0 

0.0 

1.000 

Maintainability 

JBC-P  is  maintainable  and  met  its  <  0.50-hour  Mean  Time  To  Repair  (MTTR)  user 
requirement,  demonstrating  an  MTTR  of  0.43  hours  (26  minutes)  (Table  4-6).  The  majority  of 
maintenance  events  were  related  to  software  failures,  and  the  unit  could  correct  most  of  these 
through  user  or  organic  maintenance.  Soldiers  with  Military  Occupational  Specialty  25U  (signal 
support  specialist)  accomplished  most  organizational  maintenance. 
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Table  4-6.  Mean  Time  To  Repair  (MTTR)  for  all  JBC-P  Platforms 


NIE  14.2  MOT&E  MTTR  (Requirement  <  0.50  hrs) 

Level  of  Maintenance 

Maintenance  Time  (hrs) 

Number  of  Events 

MTTR 

Crew 

6.00 

34 

0.18 

Organization 

4.10 

9 

0.46 

Unit  (Crew  +  Organization) 

10.25 

36 

0.28 

FSR 

5.17 

6 

0.86 

TOTAL 

15.42 

36 

0.43 

FSRs  were  necessary  for  6  of  the  36  maintenance  actions  (17  percent)  listed  in  Table  4-6. 
Seventeen  percent  is  high  for  FSR  support,  but  it  is  consistent  with  previous  testing,  with  the 
exception  of  the  JBC-P  IOT&E  at  NIE  13.2.  At  the  IOT&E,  JBC-P  experienced  a  high  number 
of  KGV-72  failures  that  were  resolved  by  unit  maintenance  actions,  which  suppressed  the  FSR 
support  percentages.  The  high  percentage  of  FSR  support  during  MOT&E  is  consistent  with 
Soldier/Marine  comments  that  they  need  more  maintenance  training  to  reduce  reliance  on  FSRs. 

Training 

The  Army  did  not  provide  sufficient  collective  training  (unit-level,  hands-on  training)  for 
Soldiers  and  Marines  to  gain  proficiency  on  the  JBC-P  system.  Soldiers  and  Marines  received 
New  Equipment  Training  (NET),  but  following  NET  and  JBC-P  installation,  units  did  not  have 
sufficient  time  to  conduct  collective  training,  which  is  necessary  to  reinforce  JBC-P  individual 
skills  and  integrate  the  system  into  brigade  mission  command  operations.  The  absence  of 
collective  training  reduced  the  units’  ability  to  employ  the  full  capabilities  of  the  JBC-P  system. 
Leaders  estimated  that  they  would  need  at  least  a  month  of  collective  training  for  the  unit  to 
become  proficient  with  JBC-P  operating  within  brigade  operations.  The  JBC-P  MOT&E 
highlighted  the  following  observations: 

•  Additional  MOS  25U  Soldiers  are  needed  at  the  unit  level  to  support  the  numerous 
communications  and  mission  command  systems  being  fielded  within  the  Army. 

•  Individual  training  provided  the  knowledge  and  skills  to  enable  new  users  to  operate 
and  maintain  JBC-P. 

•  Due  to  the  novice  level  of  training,  the  NET  operators’  course  did  not  provide 
substantial  benefit  for  experienced  Soldiers  with  previous  knowledge  of  Force  XXI 
Battle  Command  Brigade  and  Below  (FBCB2),  Joint  Capability  Release  (JCR),  or 
JBC-P  gained  from  participation  in  previous  NIEs  or  experience  from  previous  units. 

•  Soldiers  requested  that  the  NET  operator’s  course  include  troubleshooting  and  hands- 
on  training,  and  that  maintainers  receive  more  in-depth  technical  maintenance 
training  in  the  maintainers’  course. 

•  Soldiers  and  Marines  requested  a  leaders’  NET  that  would  focus  on  the  capabilities 
provided  by  JBC-P.  This  course  would  train  the  use  of  JBC-P  by  job  position,  with 
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focus  on  Platoon  Leader,  Platoon  Sergeant,  Company  Commander,  TOC  Staff 
Officer,  and  other  key  staff  positions. 

•  The  Army  should  provide  the  2-1  Brigade  and  all  fielded  units  with  a  Digital 
Standard  Operating  Procedure  (SOP)  to  define  the  complex  setup  of  the  JBC-P  within 
the  brigade’s  complex  mission  command  network.  This  SOP  should  include  the 
tactics,  techniques,  and  procedures  for  employing  JBC-P. 

•  The  unit  received  a  limited  number  of  technical  manuals  for  operators.  Units  were 
supposed  to  receive  technical  manuals,  but  many  reported  that  they  did  not  have 
them.  Operators  had  the  NET  compact  discs  (CD),  but  in  the  field,  there  was  no 
place  to  use  a  CD.  The  JBC-P  system  maintained  digital  technical  manuals  on  its 
hard  drive,  but  if  the  system  failed,  this  resource  is  not  available. 

•  JBC-P  Log  training  provided  to  Soldiers  was  not  effective.  Operators  required 
retraining  by  FSRs  at  the  beginning  of  Record  Test.  The  training  provided  did  not 
prepare  the  Soldiers  to  operate  or  maintain  JBC-P  Log  at  the  individual  or  unit  level. 

Interoperability 

The  JBC-P  Software  Build  6.0  MOT&E  demonstrated  joint  interoperability  of  JBC-P 
between  the  Army  and  Marines.  Soldiers  and  Marines  executed  JBC-P  functions  to  include  C2 
messaging,  Situational  Awareness,  Survivability,  and  Chat  across  Army  and  Marine  units.  The 
Army  and  Marines  demonstrated  JBC-P’ s  ability  to  reconfigure  units  through  Unit  Task 
Reorganizations  (UTRs)  across  and  within  services. 

There  were  a  total  of  282  JBC-P  systems  and  many  earlier  versions  of  FBCB2  (i.e., 
FBCB2  Version  6.5  and  JCR)  participating  in  the  MOT&E  to  support  the  Army  and  Marine 
units.  JBC-P  demonstrated  both  interoperability  and  backwards  compatibility.  The  Army 
instrumented  both  Anny  and  Marine  JBC-P  and  FBCB2  systems  to  collect  data.  Data  collectors 
embedded  within  the  units  collected  manual  data  and  observations  on  both  systems. 

Logistics  Supportability 

The  Army  demonstrated  the  JBC-P  logistics  supportability  plan  in  a  logistics 
demonstration  event  concurrent  with  the  JBC-P  MOT&E.  Brigade  Soldiers  performed  a  total  of 
350  maintenance  tasks  during  the  logistics  demonstration  and  validated  8  technical  manuals. 

The  Marines  conducted  their  own  organic  logistics  and  maintenance  support  within  the  battalion, 
employing  the  support  of  their  four  MOS  2800,  Data/Communications  Maintenance  Specialists 
and  the  brigade  FSR  assigned  to  their  battalion. 

The  Life  Cycle  Support  Plan  (LCSP)  outlines  operator-level  basic  preventive 
maintenance  checks  and  services  and  basic  troubleshooting  in  accordance  with  the  operator 
technical  manual.  The  LCSP  details  the  field-level  (organization’s  signal  support  specialist  - 
MOS  25U)  maintenance  tasks  consisting  of  troubleshooting  hardware,  software,  and  the 
network.  The  signal  support  specialist  tasks  include  removing  and  replacing  line  replaceable 
units,  hard  drive,  and  faulty  KGV-72  devices.  All  maintenance  actions  above  the  field  level 
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signal  support  specialist  are  perfonned  by  a  contractor  FSR  controlled  by  the  Brigade  Support 
Battalion. 

The  Army  executed  the  LCSP  during  the  JBC-P  MOT&E.  Operators  (vehicle  and  TOCs) 
and  unit  maintainers  were  able  to  troubleshoot  JBC-P  system  faults  and  return  the  system  to 
operation  83  percent  of  the  time,  with  the  FSRs  being  called  in  for  17  percent  of  system  failures. 
The  Soldier  and  Marine  maintainers  and  operators  stated  that  it  was  easy  to  conduct  preventive 
maintenance  checks  and  services.  Maintainers  and  operators  were  hindered  in  repairing  JBC-P 
due  to  lack  of  spares  such  as  cables,  batteries,  and  fuses.  Unit  maintainers  completed  the  NET 
Field  Level  Maintainers  Course  and  rated  the  course  as  effective  in  providing  the  Soldiers  and 
Marines  with  sufficient  knowledge  to  complete  their  maintenance  tasks.  The  operators  noted 
that  the  operator’s  NET  should  contain  more  troubleshooting  and  maintenance  at  their  level.  At 
the  operator  level,  maintenance  consists  of  rebooting  the  system.  The  logistics  company  in  the 
Brigade  Support  Battalion  is  not  authorized  a  signal  support  specialist  (as  allocated  to  maneuver 
companies),  which  hampers  the  maintenance  of  the  JBC-P  Log  systems  within  the  unit.  To 
support  their  JBC-P  Log  systems,  the  logistics  company  cross-trained  a  unit  fuel  handler  to 
perform  the  signal  support  specialist  job.  This  provided  support  for  JBC-P  Log,  but  removed  the 
Soldier  from  performing  his  assigned  mission  within  the  unit. 


38 


Section  Five 

Recommendations 

The  Army  and  Marine  Corps  should  consider  the  following  actions  to  improve  Joint 
Battle  Command-Platform  (JBC-P)  Software  Build  6.0: 

•  Improve  Effectiveness.  The  Army  should  improve  JBC-P  support  to  unit  mission 
accomplishment. 

-  Fix  position  location  identification  icon  deficiencies  to  include  false  location, 
lagging,  and  racing  icons. 

-  Correct  unit  command  and  control  alerting,  i.e.  eliminate  phantom  Mayday 
messages. 

-  Improve  shared  survivability  information  to  enable  better  retrieval  and/or  caching 
of  relevant  Entity  Data  Message  map  icons. 

-  Fix  map  deficiencies  to  include  zoom  and  grid  line  accuracy  problems. 

-  Improve  the  performance  of  the  communications  security  device,  KGV-72. 

-  Improve  noted  JBC-P  Log  deficiencies. 

-  Demonstrate  improvements  in  a  future  operational  test. 

•  Improve  Reliability.  The  Army  should  improve  JBC-P’ s  reliability. 

-  Identify  and  fix  failure  modes  for  the  MRT+  and  inconsistent  reliability 
performance  for  the  MFoCS  configurations. 

-  Demonstrate  improved  reliability  in  an  operational  test  prior  to  full  materiel 
release  and  subsequent  fielding  of  the  JBC-P  Software  Build  6.0. 

•  Improve  Training.  The  Army  should  improve  JBC-P  New  Equipment  Training. 

-  Provide  JBC-P  collective  training  that  validates  both  individual  and  unit 
proficiency.  Expand  collective  training  to  include  JBC-P  Log. 

-  Expand  the  leader’s  course  to  provide  more  JBC-P  information  tailored  to  the 
individual  command/staff  position  to  allow  the  full  use  of  its  mission  command 
capabilities. 

-  Expand  the  operator’s  course  to  include  more  hands-on  training  and  provide  more 
detail  on  trouble  shooting  beyond  doing  a  system  “reboot.” 

-  Include  training  on  all  JBC-P  components,  e.g.  KGV-72  encryption  device,  to 
enable  Soldiers  to  install,  operate,  and  maintain  the  system. 

•  Create  a  Digital  Standard  Operating  Procedure  (SOP).  The  Army  and  Marine 
Corps  should  create  a  digital  SOP  to  integrate  the  numerous  mission  command 
systems  with  their  services.  This  document  should  standardize  mission  command 
operations  for  both  tactical  operational  centers  and  on-the-move  systems. 
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•  Increase  Signal  Soldier  Manning.  The  Army  should  evaluate  manning  of  Signal 
Soldiers,  e.g.  Military  Occupational  Specialty  25U,  across  the  brigade  to  support 
JBC-P  and  other  networked  systems.  The  Army  should  conduct  a  holistic  assessment 
of  mission  command  systems  with  accompanying  communications  systems  and  staff 
their  units  for  mission  success. 

•  Improve  Survivability.  The  Army  should  address  the  deficiencies  and 
recommendations  noted  in  the  classified  annex  of  this  report. 
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